Notes by Brendan Foote
Design and Analysis of Cyber-Physical Systems: AADL and Avionics Systems
Julien Delange and Peter Feiler, SEI
Architectural decisions affect nonfunctional requirements, which are critical to the safety of systems. Rework costs increase the later a defect is detected in the software development life cycle. In Delange’s experience, a $10,000 architecture-phase correction can save $3 million! These errors can be caused by mismatched assumptions in embedded software. One anecdote is a train on which the doors wouldn’t close, so the conductor stepped outside to push them closed. But the system assumes the conductor is inside, so the train automatically took off. Dual core laptops also violated many assumptions that developers had made up to that time. To put it glibly, if we can’t get iTunes right on dual core machines, how are we supposed to make safe airplanes with even more complicated hardware?
But the more generic question is why do system-level failures still occur despite fault-tolerance techniques in the deployed system? System-level fault root causes can come from violation of data stream assumptions, such as stream miss rates, mismatched data representation, latency jitter, and age.
This can be combated with an architecture-centric modeling approach, which addresses change impact across analytic models and nonfunctional properties, including safety and reliability, data quality, and many others.
Using the AADL and simulation, defects can be caught much earlier. Failure modes and effects analyses are rigorous and useful as well. These processes can be used to support an ATAM process. The bottom line is that there are tests that can be performed throughout a development life cycle that can detect problems as early as possible.
Tailoring a Method for System Architecture Analysis
Joakim Fröberg, Mälardalen University
Stig Larsson, Effective Change AB
Per-Åke Nordlander, BAE Systems AB
When faced with a method for system-architecture analysis that didn’t meet their needs, Fröberg and his colleagues had to develop their own. Their goal was the get better fuel efficiency out of mining vehicles, which they proposed doing by introducing efficient hybrid electrical drive systems. One challenge was how to leverage the architecture for vehicles beyond the heavy construction ones being considered here. And their scope included both the architecture of the software and the electrical systems involved.
They started with stakeholder analysis and system boundary definition. This resulted in five subsystems, of which the maintenance system seemed to have the largest number of issues. To analyze their options, they first collected all the contextual information they could find. But they needed a process for making their choice after that, so they went to the community of practitioners to ask what they thought. They had several criteria for the process:
- supports selection between candidates
- has a small footprint
- covers the complete system usage and scope
- is based on quantifiable entities
- provides analysis results early in development
The candidates for this process were Firesmith’s MFESA, Kazman’s ATAM, Axelsson’s ALCEA, Muller’s CAFCR, and INCOSE’s SE guidelines.
But instead they created use cases for every aspect of the system, grouped them by area, and evaluated each of three candidates with a specific number. When they summed them up, they came to a decisive conclusion that was counter to their gut sense. However, creating a method takes time!
Architecting for User Extensibility
Russell Miller, SunView Software, Inc.
When you open up a system, should you spend all your time architecting for users to change in any way they want? Well, Salesforce and QuickBase are examples of platforms that are doing just that. And customers are starting to have expectations for extensible systems, like not requiring any downtime to deploy an extension.
On the other side, there are technical challenges for building extensible systems, like performance, database schema, UI binding, domain-specific language, and added complexity due to metamodel. Russell’s company tackled these issues by separating the what, the how, and the views right off the bat. They created a business-logic engine and adaptive-object model to put these things together dynamically. They also used module packages that are re-deployable, versionable, sharable, secured/controlled, isolated, and UI editable. He points out that the need for this is highlighted by cloud-deployed systems, since there is no opportunity to drop a DLL in the system to change how it behaves, for example.
The business rules defined by the user are compiled down to actual code, and database tables are dynamically generated, so it is possible for developers to inspect the state of the system using normal means.