Agile and Model-Based Design for Engineering Software Development
By Roger Aarenstrup and Gaurav Tomar, bat365
Most teams developing software for engineering applications today recognize the drawbacks of traditional (waterfall) methodologies. These include the discovery of defects and design problems in the later stages of a project, the inability to accommodate changes in requirements, and the risk of delivering a system that does not meet customer needs.
To overcome these drawbacks, many teams have adopted an approach that combines agile methods with Model-Based Design.
An examination of Model-Based Design and agile methods shows that Model-Based Design complements and even enables agile for engineering applications. Like agile, Model-Based Design originated to support fast iterations. It also meets system engineering challenges not addressed by agile alone:
- How to perform early tests without access to equipment
- How to manage engineering system complexity
- How to mitigate the risk of testing unproven software on costly hardware
- How to satisfy the requirements of functional safety and other standards, including DO-178B/C and ISO 26262
This article explains how Model-Based Design supports the core values of agile development, with an adaptive cruise control example that combines Model-Based Design with agile methods and the Scrum framework.
Agile and Model-Based Design: The Basics
Agile software development methods are built on the core values and principles outlined in the Agile Manifesto, published in 2001. Today, one of the most widely used frameworks for agile development is Scrum. In Scrum, development proceeds in a series of cycles called sprints, in which the team works on a subset of features in the project backlog for a time-boxed period (typically, between one or two weeks and a month). In each sprint, the team develops, tests, integrates, and documents working software (Figure 1).
Figure 1. Agile development using the Scrum framework.
Model-Based Design is a model-centric approach to the development of systems. Rather than relying on physical prototypes and textual specifications for communication, Model-Based Design uses a model throughout development. The model includes all components relevant to system behavior—algorithms, control logic, physical components, and the environment. Once the model is developed (elaborated), it can be used to generate code (C/C++, HDL, or Structured Text), reports, and other kinds of documentation. The core components of Model-Based Design are system-level and component-level design and simulation, automatic code generation, and continuous test and verification.
Mapping the Core Values of Agile to Model-Based Design
The Agile Manifesto defines four core values for developing software:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The manifesto authors point out that "over" does not mean "not". What they propose is a shift of emphasis: “While there is value in the items on the right, we value the items on the left more.”
Let’s see how these agile values map to Model-Based Design.
Focusing on Individuals and Interactions
The processes and tools in Model-Based Design—in particular, modeling and simulation—foster productive interactions among individuals and teams. The model can be shared directly in Simulink®, in a report, or as a web page, enabling all stakeholders to use it as a common reference point and single source of truth. Simulation results are clear and visible, and can facilitate design decisions, Scrum planning, and discussions with stakeholders.
Focusing on Customer Collaboration
Customer collaboration is central to agile methods. Each sprint kicks off with a planning meeting and ends with a review meeting, where customers are often invited to provide input. Modeling and simulation not only support productive customer collaboration, but also enable collaboration across teams, domains, and disciplines. Engineers from hardware design, system design, and function and component development have a common language and can focus on working together rather than worrying about tools.
Focusing on Working Software
One of the principal advantages of Model-Based Design for a team using agile is the ability to develop a working version of the system from their earliest sprints, even if the embedded target, plant, sensors, or other hardware is unavailable. A Simulink model verified via simulation can serve as working software throughout the project. A model acts as an executable specification of the system under development. In early sprints, when hardware may be unavailable, simulation results can be shared with the customer in lieu of hardware test results and used to gauge progress, solicit buy-in, or plan the next sprint. Models also provide a clear and convenient way to measure progress. As the model is elaborated, it can be used to generate code for software-in-the-loop (SIL), processor-in-the-loop (PIL), and hardware-in-the-loop (HIL) tests as well as for real-time prototypes and production systems.
The model also serves as the basis for comprehensive documentation. In Model-Based Design, documentation is an output of the design process, not a discrete task, and documentation and reports can be generated from the model on demand.
Focusing on Responding to Change
A major stumbling block of waterfall development is the inability to respond adequately to evolving requirements and conditions. Agile development and Model-Based Design address this drawback and enable teams to respond to change more effectively. For any nontrivial change in an engineering application, engineers using Model-Based Design can modify the model and then simply regenerate code. Before any changes are implemented, the team can run what-if analyses to determine the best way to accommodate a particular change request. After changes are made in the model, engineers can run simulations for regression tests to ensure that the changes do not cause unintended behavior in the system. And when the model is linked to requirements, the team can perform impact analyses to understand how a change to one part of the model will affect other parts.
Use Case: Combining Agile Methods with Model-Based Design to Develop an Adaptive Cruise Controller
In this example, an automotive engineering team is developing software for an adaptive cruise control system with sensor fusion. The system fuses input data from on-board radar and vision sensors to identify the most important object and its distance from the ego vehicle to adapt speed and maintain safe distance.
On this project, one group of engineers works on developing the control algorithms while another develops driving scenario and synthetic sensor data. This synthetic data will enable the engineers to develop and test the algorithms well before actual sensor data becomes available. Early simulations using synthetic data can inform design decisions, such as the type, number, and positioning of in-vehicle sensors.
In the first sprint, each sub-team (or group of engineers) models its respective subsystems, using a shared system-level Simulink model to coordinate their work (Figure 2). Even at this early stage, they can run simulations to see how the controller behaves under various conditions. They debug the controller, identify parameters to be optimized, and visualize key performance metrics from a working version of the system—all before writing or generating a single line of code.
Figure 2. Simulink model of an adaptive cruise control system with sensor fusion.
During a review meeting with the customer toward the end of the first sprint, they share the model and the simulation results (Figure 3). The model and results provide a concrete representation of the working software—for example, by illustrating how the vehicle’s velocity decreases after another vehicle shifts into its lane.
Figure 3. Simulation results from the adaptive cruise control model.
In subsequent sprints, the teams refine or enhance the model based on customer feedback—for example, by adjusting the safe following distance or altering the rates at which the vehicle accelerates or decelerates—and optimize it for code generation and deployment to the ECU. The generated code may be used as is or integrated with legacy code as part of a larger system. Continuous integration (CI) with Jenkins™ is used to continuously check integration of generated and manual code, run tests on the model, check for compliance with modeling standards, and later, perform tests on the generated code. Results from all these activities are reported automatically to track progress and for stakeholders not using development tools.
In later sprints, the teams incorporate more rigorous verification and validation activities, including SIL, PIL, or HIL tests, to ensure that the design meets requirements. They also check that the models and code comply with established standards and guidelines, use static analysis and formal methods to prove the absence of critical run-time errors, and produce reports and other artifacts in preparation for standards certification.
As the project progresses, customer needs can shift. For example, the customer might request model predictive control rather than a classical control algorithm because an advanced MPC controller enables the vehicle to react to more aggressive maneuvers by other vehicles in the environment. Because a system model is being used on this project, the algorithm team can easily replace the original control algorithm with a newly developed model predictive controller and leave the rest of the model unchanged. The team reruns the simulations and shares the results with the customer. An informed decision can then be made on whether to proceed with the design change or revert to the previous approach.
This team used Model-Based Design within their agile development workflow and delivered working software well before hardware was involved. Modeling and simulation enabled the team to continuously improve the design based on customer feedback, and even accommodate a significant requirement change late in the project.
Published 2018
