Podcasts about architecture analysis

In this SEI Podcast, Aaron Greenhouse, a senior architecture researcher with Carnegie Mellon University's Software Engineering Institute, talks with principal researcher Suzanne Miller about use of the Bell–LaPadula mathematical security model in concert with the Architecture Analysis and Design Language (AADL) to model and validate confidentiality. Greenhouse and Miller also discuss 11 analysis rules that must be enforced over an AADL instance to ensure the consistency of a security model. Mapping Bell–LaPadula to AADL allows the expression of key concepts within the AADL model so that they can be analyzed automatically.   

Sam Procter a researcher at the Software Engineering Institute of Carnegie Mellon University discusses Security in Software design. Justin Beyer spoke with Procter about Architecture Design Languages, specifically Architecture Analysis and Design Language (AADL) about what it is, how it can be used for security and privacy. Specifically, he discussed AADL, the tooling that is […]

Sam Procter of the SEI discusses architecture design languages, specifically Architecture Analysis and Design Language, and how we can leverage the formal modeling process to improve the security of our application design and improve applications overall.

Classifying errors in a component-based system is challenging. Components, and the systems that rely on them, can fail in myriad, unpredictable ways. It is nonetheless a challenge that should be addressed because component-based, software-driven systems are increasingly used for safety-critical applications. In this podcast, SEI researchers Peter Feiler and Sam Procter present the Architecture Analysis and Design Language (AADL) EMV2 Error Library, which is an established taxonomy that draws on a broad range of previous work in classifying system errors.

In this podcast, Peter Feiler describes a textual requirement specification language for the Architecture Analysis & Design Language (AADL) called ReqSpec. ReqSpec is based on the draft Requirements Definition and Analysis Language Annex, which defines a meta-model for requirement specification as annotations to AADL models. A set of plug-ins to the Open Source AADL Tool Environment (OSATE) toolset supports the ReqSpec language. Users can follow an architecture-led requirement specification process that uses AADL models to represent the system in its operational context as well as the architecture of the system of interest. ReqSpec can also be used to represent existing stakeholder and system requirement documents. Requirement documents represented in the Requirements Interchange Format can be imported into OSATE to migrate such documents into an architecture-centric virtual integration process. Finally, ReqSpec is an element of an architecture-led, incremental approach to system assurance. In this approach, requirements specifications are complemented with verification plans. When executed, these plans produce evidence that a system implementation satisfies the requirements. Listen on Apple Podcasts.

The Department of Defense (DoD) must focus on sustaining legacy weapons systems that are no longer in production, but are expected to remain a key component of our defense capability for decades to come. Despite the fact that these legacy systems are no longer in the acquisition phase, software upgrade cycles are needed to refresh their capabilities every 18 to 24 months. In addition, significant modernization can often be made by more extensive, focused software upgrades with relatively modest hardware changes. In this podcast, Mike Phillips discusses effective sustainment engineering efforts in the Army and Air Force, using examples from across its software engineering centers. These examples are tied to SEI research on capability maturity models, agility, and the Architecture Analysis and Design Language (AADL) modeling notation. Listen on Apple Podcasts.

Safety-critical systems, such as those used in avionics and the medical and aerospace domains, are becoming increasingly reliant on software. Malfunctions in these systems can have significant consequences, including mission failure and loss of life. As a result, they must be designed, verified, and validated carefully to ensure that they comply with system specifications and requirements. A car contains many electronic control units (ECUs)—today’s standard vehicles can contain up to 30 ECUs—that communicate to control systems such as airbag deployment, antilock brakes, and power steering. The design of tightly coupled software components distributed across so many nodes may introduce problems, such as early or late data delivery, loss of operation, or concurrent control of the same resource. In addition, errors introduced during the software design phase, such as mismatched timing requirements and values beyond boundaries, are propagated in the implementation and may not be caught by testing efforts. If these problems escape detection during testing, they can lead to serious errors and injuries. Also, because such systems are designed to be operational for many years, errors are often found when reviewing code from legacy systems designed and built more than 20 years ago and still operating, as in the avionics and aerospace domains. Unfortunately, late discovery of errors leads to major rework efforts and often postpones product delivery. Such issues are not specific to a particular domain and may occur in all in safety-critical systems. During the last 10 years, SEI researchers have been working on methods, languages, and tools to design safety-critical systems, find potential issues at the earliest phase in the development process, and avoid potential re-engineering efforts. Our techniques help system architects design the system and check requirements enforcement without having to implement the system. This webinar introduces the Architecture Analysis and Design Language (AADL), the architecture modeling language used to specify safety-critical systems. We show its use in the Open Source AADL Tool Environment (OSATE) to design and validate a generic automotive application—a speed-regulation system. In particular, this webinar will demonstrate analysis capabilities of the tool for different perspectives, including resources budgets, performance/latency, and safety.

Given that up to 70 percent of system errors are introduced during the design phase, stakeholders need a modeling language that will ensure both requirements enforcement during the development process and the correct implementation of these requirements. Previous work demonstrates that using the Architecture Analysis and Design Language (AADL) early in the development process not only helps detect design errors before implementation but also supports implementation efforts and produces high-quality code. Previous research has demonstrated how AADL can identify potential design errors and avoid propagating them through the development process. Verified specifications, however, are still implemented manually. This manual process is labor intensive and error prone, and it introduces errors that might break previously verified assumptions and requirements. For these reasons, code production should be automated to preserve system specifications throughout the development process. In this podcast, Julien Delange summarizes different perspectives on research related to code generation from software architecture models. Listen on Apple Podcasts.

In this podcast, Julien Delange discusses two extensions to the Architecture Analysis and Design Language: the behavior annex and the error-model annex. The behavior annex represents the functional logic of AADL components and interacts with the other system elements. SEI researchers are currently participating in the ongoing improvements of this extension of the AADL by connecting it to other analysis tools. The error model annex augments the architecture description by specifying safety concerns of the system (error propagation, error behavior, etc.). The language is the foundation of new analysis tools that provide qualitative and quantitative assessment of system safety and reliability. SEI researches have defined new tools that analyze the model and produces safety validation documents, such as the one required by safety standard such as the SAE ARP4761.  Listen on Apple Podcasts.

In this episode, Peter Feiler, primary author of the Architecture Analysis & Design Language (AADL) standard, discusses the latest changes to the standard, the second version of which was released in January 2009. First published in 2004 by SAE International, AADL is a modeling notation that employs both a textual and graphical representation to provide modeling concepts to describe the runtime architecture of application systems in terms of concurrent tasks, their interactions, and their mapping onto an execution platform. Development organizations use AADL to conduct lightweight, rigorous, yet comparatively inexpensive analyses of critical real-time factors such as performance, dependability, security, and data integrity. Listen on Apple Podcasts.

In this episode, Julien Delange and Peter Feiler discuss the latest developments with the Architecture Analysis and Design Language (AADL) standard. First published in 2004 by SAE International, AADL is a modeling notation that employs both a textual and graphical representation. AADL provides modeling concepts to describe the runtime architecture of application systems in terms of concurrent tasks, their interactions, and their mapping onto an execution platform. Development organizations use AADL to conduct lightweight, rigorous, yet comparatively inexpensive analyses of critical real-time factors such as performance, dependability, security, and data integrity. Listen on Apple Podcasts.

During Evolution of a software system, it becomes more and more difficult to understand the originally planned software architecture. Often an architectural degeneration happens because of various reasons during the development phases. In this session we will be looking how to avoid such architectural decay and degeneration and how continuous monitoring can improve the situation (and avoid architectural violations). In addition we will look at "refactoring in the large" and how refactoring can be simulated. A new family of "lint like tools for software architectures" is currently emerging in the marketplace I will show some examples and how they scale and support you in real world projects.

During Evolution of a software system, it becomes more and more difficult to understand the originally planned software architecture. Often an architectural degeneration happens because of various reasons during the development phases. In this session we will be looking how to avoid such architectural decay and degeneration and how continuous monitoring can improve the situation (and avoid architectural violations). In addition we will look at "refactoring in the large" and how refactoring can be simulated. A new family of "lint like tools for software architectures" is currently emerging in the marketplace I will show some examples and how they scale and support you in real world projects.

During Evolution of a software system, it becomes more and more difficult to understand the originally planned software architecture. Often an architectural degeneration happens because of various reasons during the development phases. In this session we will be looking how to avoid such architectural decay and degeneration and how continuous monitoring can improve the situation (and avoid architectural violations). In addition we will look at "refactoring in the large" and how refactoring can be simulated. A new family of "lint like tools for software architectures" is currently emerging in the marketplace I will show some examples and how they scale and support you in real world projects.