5 Enablers for Agility in Functional Safety Development

Functional Safety

5 Enablers for Agility in Functional Safety Development

By |

Agile development has proven a huge success for building functioning, innovative products quickly, especially software.

It is not surprising, then, that many organizations are looking for ways to apply it in areas beyond software.

In fact, this is already happening. WikiSpeed, for instance, is designing, building, testing and selling cars on a weekly scrum cycle. But would you feel comfortable in a WikiSpeed car?

There’s a long tradition of developing safety-critical systems like planes, trains, cars or medical devices. (There is the saying that federal aviation regulations were “written in blood.”)

So, it is understandable that we do not want to discard decades of experience at the risk of human life.

Not Either/Or: Both!

The foundation for functional safety development is IEC 61508 or a related standard. Key to these types of standards is the management of functional risk, which in turn requires a clear structure of the development artifacts to act as the foundation for risk analysis. Almost all standards build on the V-Model as the supporting structure, but the V-Model is often misunderstood.

Contrast this with Agile approaches, which rely on rapid development cycles. Agile methods de-emphasize the development structures, as stated in the Agile Manifesto: “Working software over comprehensive documentation.” To be fair, specific frameworks like the Scaled Agile (SAFe) fill this gap.

The challenge is to combine the principles of functional safety development with the advantages of Agile product development, without sacrificing the former. The following figure visualizes this conceptually:

We see the V-Model is the underlying structure, overlaid with an Agile continuous engineering process. For organizations that currently develop products, the V-Model is already established. The challenge is to overlay it with the Agile engineering process, without jeopardizing the existing achievements with respect to functional safety. Here are five catalysts that can help you get there.

Enabler 1: Fine-Granular Items

A surprisingly high number of organizations still use documents for various development artifacts: requirements specification, system requirements, design, etc. For a small number of items, a Word or Excel file seems adequate. But there are two problems: First, with increasing complexity, the number of items increases. Using documents does not scale.

The second is directly related to the topic of this article: Document-based development makes each iteration very expensive and creates a large overhead. Specifically, with document-based work, there is no clear understanding on what has changed within the document, and how it affects related artifacts. This, in turn, means that the complete system description must be reviewed and analyzed, not just the pieces that have changed.

Item-based work requires appropriate tool support, but also a corresponding mindset.

Enabler 2: Up to Date, Actionable Traceability

Once an organization adopts an item-based mindset, it is critical to understand and capture the relationship between the items. This is commonly known as traceability.

If maintained properly, traces help to drastically reduce the effort for an additional iteration: They point to the impact of changes from iteration to iteration, and ensure that only the “delta” between iterations need to be analyzed.

Traceability should cover the whole development chain from requirement to test – end-to-end traceability. This ensures that only the changes have to be re-tested, not everything else.

The hardest thing about traceability is keeping it up to date. This requires the right mindset (again!), as well as proper tool support that does not get in the way and is “actionable” — i.e. problems in the traceability itself and easy access for fixing it.

Enabler 3: Seamless Collaboration

With traditional development, problems are often discovered only at the end of a development cycle, especially if they relate to other subsystems. But collaboration across subsystems should happen continuously, so that issues and questions are resolved as soon as possible.

Again, this requires the right mindset, in particular the willingness for transparency and open communication. But the tools and processes must support this as well. If the tooling alerts developers immediately to the change of an upstream requirement, engineers can resolve potential problems right away.

Enabler 4: Decouple the (Sub-)Systems

It’s a nightmare scenario to have one technical change result in an avalanche that makes the whole product obsolete. A safeguard against this is to decouple the various systems and subsystems as much as possible. Treat every subsystem as a “black box” with a clearly defined interface and behavior that does not depend on the implementation.

This approach needs a good understanding of behavior-driven development by the team, but if implemented right, it can become a game changer. In addition to making the system much more robust, it also makes reuse much easier and efficient.

For sophisticated systems, effective black-box design may require specialized Model Based Systems Engineering (MBSE) approaches and tools.

Enabler 5: Different Speed for Software and Hardware

When decoupling systems as described above, we recommend acknowledging the fact that hardware and software are fundamentally different, yet need to evolve together.

In addition to decoupling, software and hardware development can happen at a different pace. It’s a fact that hardware changes slower than software, and the cycle speed should reflect this.

Working at different speeds makes it even more important to align on a regular basis, and to collaborate continuously. In practice, this means that hardware and software have common stakeholder requirements, and that changes in those must trigger a collaboration with software and hardware groups to react accordingly.

It took decades to learn how to build safe products – let’s not discard what we have learned. Instead, let’s augment existing practices with new insights from Agile development.

To apply them, we need a new mindset, new tools and the willingness to incrementally transform the way we develop products. The five enablers shown here provide some guidance on how to achieve this.

If these ideas resonate with you, consider attending ECS 2018 in Stockholm, Europe’s largest embedded conference. There, author Michael Jastram will deliver a talk, “Agile Development of Embedded Systems for Functional Safety – a Contradiction in Terms?”

Michael Jastram
Latest posts by Michael Jastram (see all)