Advertisement

Blogs Tales from the Cube

Functional safety vs. Agile: Calling a truce

Advertisement

chalk drawing of two hands shaking on a chalk board to symbolize cooperation between functional safety and AgileHas 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.

Advertisement

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.

Advertisement

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?

https://www.edn.com/wp-content/uploads/2012/08/tales-button.png?resize=229%2C48We’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?

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:

7 comments on “Functional safety vs. Agile: Calling a truce

  1. MWagner_MA
    April 16, 2021

    The reason why the debates about requirements is ever present is that we loose focus of what requirements define. In my opinion requirements define WHAT you want the product to do, and the HOW is left to the engineers to apply their creativity (or insert Agile here). Now there will many times be a case where the HOW needs to be specified in safety critical sections where a given method is KNOWN to work well, but even there a healthy discussion among team members can challenge that as well with the end result standing more on the side of SAFETY than creativity.

    As far as contracts go, it is one of the MOST important thing to get right because that is what you get paid from and what may keep you out of the courts. No amount of creativity (like when software is substituted for redundant hardware in the 737-Max) will save you when your product fails and you are hit with a massive lawsuit. The contract is to clearly state to BOTH parties what the other can expect. Again, here is where both parties need to state WHAT they want done and not necessarily HOW unless it is that important (like redundant hardware) and if it is, it needs to be in the contract. As you learn more about the needs of the customer, that is what contract amendments are for if a “better way” is found.

    • MarkPitchford
      April 20, 2021

      I wouldn’t disagree with any of that for the markets and circumstances for which you quote your examples.. But there are situations where safety critical (and other) products are developed on an ongoing basis; the subjects of a policy of continuous improvement. For these development teams, there are no contractual obligations and nothing to insist that any particular features must be present by any particular dates. It’s an extension of the notion that new start-ups may well be working on a great idea to bring to market which will clearly aim to fill a need, but the hows and whys may be no more detailed than that.

      In short, I feel that there are many who seek to belittle any iterative process that doesn’t put detailed requirements first and central to everything. I don’t doubt that it is perfect for many, probably most, safety critical applications. But I am also arguing that it is not the only way in which high quality, highly reliable, safety critical software can be developed.

  2. MWagner_MA
    April 20, 2021

    Well said Mark. I agree in less critical applications there is much more room for going “off script”, but I think both concepts can coexist, and I think ALL development can benefit from thinking through a very basic set of requirements to provide a target for where a design is headed. Otherwise, how can you coordinate electronic, mechanical and software? The trick is to talk about WHAT you may want, now how it gets done. That is the mistake I have seen with contracts. Good article as it gets people thinking about how to embrace creativity with some structure.

  3. KentBurr
    June 9, 2023

    Just a caution. Great discussion about development. However it doesn’t come down to what you can design/build. What matters in this area is what you can get certified. I don’t know the automotive FuSa standards and requirements, but have some experience with 61508. Make sure that you have a certifying agency on board, or you will have a non-technical challenge ahead of you!

    • MarkPitchford
      June 20, 2023

      Absolutely. That said, certification bodies of any kind (whether they are independent or from the purchasers of your product) insist on these things because they represent best practice, not to be awkward!

  4. Brian park
    June 10, 2023

    This article makes no sense whatever to me. It sounds like something taught in one of those courses that companies FORCE one to take, such as “total quality management”, or “sexual harassment training”, offsite, by high-dollar “training companies”. I was looking for some sort of “punch line”, or “words of wisdom”, & it is not there, other than for some industries (such as aircraft) where attention to detail is important. So what’s new? There is something about “just getting it to work”, & “old vs new software”, but what? Also mixed in is something concerning aircraft certification?
    The article spans so much timeframe that the various parts are disconnected.

    • MarkPitchford
      June 20, 2023

      Sorry you feel that way. Can’t win ’em all! It’s a contribution to a “tales from the cube” series which is itself retrospective in nature. Perhaps you’ve not come across the Agile/FuSa debate?

Leave a Reply