Ending the confrontation between functional safety and Agile software
Article By : Mark Pitchford
When it comes to confrontation between the functional safety and Agile software worlds, there is truth on both sides and a less healthy helping of vested interest.
Has the time come to call a truce between functional safety and Agile software development?
In my first real software job in the early 1980s, I worked in a company that made metrology equipment. At the time, I didn’t really see myself as a software developer; the software was merely a malleable means to the application of engineering math.
Back then, affordable computing power had just started to make things possible. Led by the most capable all-round engineer I have ever known, we developed a package that was capable of accurately measuring the planes, lines, circles, spheres, and cones that go to make up most engineering components. Think piston engine cylinder head, and you’ll get the idea.
Then we started to push the boundaries. What about components that weren’t made up of basic geometric shapes? Based in Derby, England, a hotbed of aerospace engineering, the burning question of the day concerned how you might go about measuring a turbine blade on a coordinate measuring machine. It mattered because turbine blades are very expensive components, and working out whether one is scrap or can be machined back to being within tolerance is by no means an intuitive process. Solve that conundrum and we had a ready and eager internationally-renowned customer on our doorstep.
It’s a challenge that has long been solved, but at that time, we were pushing the boundaries. There was a lot of brainstorming, and lot of trial and error. Gradually trying ideas, building on the successful ones, and after many false dawns, eventually achieving something that worked, at least most of the time. And then? We sent it out the door.
The rise of FuSa
Fast forward 40 years, and as I write this, I work for a company that helps others adhere to functional safety (FuSa) standards. A majority of those standards dictate that a “requirements first, code later” approach is paramount. There is good reason for that. Once our metrology software was sent to the customer, there followed a period of extensive support where glitches and bugs were attended to over time.
This was tolerated because it was ground-breaking stuff, but had the software been controlling the engines it was measuring, then no such second chances at getting the software right would exist without catastrophic consequences. Passenger aviation has had an enviable reputation for safety for a very long time, and a large part of that is down to the strict adherence with DO-178 in its various forms. Compromise that, and you’re playing with fire, as the experiences with the Boeing 737-MAX will testify.
More recently, those same principles have been rolled out across the safety-critical sectors. We have IEC 61508 as a generic standard, applicable to electronic control devices in its own right. And that has begat several industry-specific variants, including ISO 26262 in the automotive industry and IEC 62304 for medical-device development.
And the rise Agile
There is, however, another school of thought. The manifesto for Agile software development was elucidated by one of its founders, Scott Ambler, as follows:
- Tools and processes are important, but it is more important to have competent people working together effectively.
- Good documentation is useful in helping people to understand how the software is built and how to use it, but the main point of development is to create software, not documentation.
- A contract is important but is no substitute for working closely with customers to discover what they need.
- A project plan is important, but it must not be too rigid to accommodate changes in technology or environment, stakeholders’ priorities, and people’s understanding of the problem and its solution.
These are simple principles, and on the face of it, much more in harmony with the development of our metrology software back in the day. But they don’t fit in well with the principles of FuSa standards as they are written. They don’t guard against the period of extensive customer support we witnessed in the 1980s, which also means that there is no obvious fit for FuSa.
Added to that, the acronyms and adaptation of these principles have grown like Topsy as the glossary from the Association for Project Management would imply. What began as a set of four simple principles has become something much larger and more florid, and critics suggest that surrounding infrastructure is becoming more important than the principles themselves.
Do you have a memorable experience solving an engineering problem at work or in your spare time? Tell us your Tale.
A false dichotomy
As with most such confrontations, there is truth on both sides here and a less healthy helping of vested interest. On the one hand, FuSa experts have invested a lot of time and energy into the development of standards that follow the same mantra of requirements first, requirements central, requirements always.
On the other hand, it’s a fact that FuSa standards pay little more than lip service to the idea that software can be an intellectual modelling clay; a medium to try, fail, improve, and hone ideas that are malleable and interactive in a way that the writing of requirements can never hope to match. Agile development supports that principle much more closely.
These things need not be mutually exclusive. That’s where the vested interest seems to take hold. If you’ve been on committees, published learned papers, and become a world-renowned expert in the One True Way in the debate between functional safety and Agile, then a seemingly contrary stance is something you will likely be inclined to challenge. Then comes the deterioration into name calling, and childish monikers such as FrAgile become popular terms. Forget constructive debate—pass me my pea shooter, or I’ll pull your hair …
Let’s take a step back. Just suppose that there is something in both of these of arguments. Forget Agile and all its confusing terminology; just consider how an iterative process might fit into a FuSa environment without denying the innovative thought stuff that a freer, more creative attitude to software engenders.
Now think back to the metrology software. What if on each cycle of development, we hadn’t simply built on each test mule to develop the next step? What if, instead, we had defined requirements based on the principles we had discovered through our creative phase? What if we had then developed software requirements, and re-written the software to fulfil them with an emphasis on its quality rather than just making something work? And only then started “playing” again, this time on sound foundations?
We’d still have had our innovative solution. Intuitively, it might have felt like it was taking longer, but the time saved in after-sales support would certainly have more than offset that. And more pertinently, had the software been an engine controller, the same principle could have yielded innovation and FuSa.
Doesn’t that offer enough promise to suggest that the pitchforks and torches wielded for and against functional safety and Agile might be better put to one side?
This article was originally published on EDN.
Mark Pitchford, technical specialist at LDRA Software Technology, has worked with development teams looking to achieve compliant software development in safety and security critical environments.
Related articles:
- Design for reliability: You have the tools
- Does Agile Development make sense for SoC design?
- Agile Hardware Development – Nonsense or Necessity?
- Coding confessions from Canada
- Functional safety: toolkit tie-ups automate software and verification analysis
- Developing safety critical ASICs for ADAS and similar automotive systems
