The need for agility in development and the need for safety in embedded software appear to be mutually exclusive. The industry is asking “Does this have to be the case?” And in fact, as we can see discussed here, and here, some are beginning to assert not only that an agile approach and meeting safety requirements shouldn’t be mutually exclusive–they certainly do not have to be. We agree.

Since the beginning of our journey at SimuQuest, we have been evolving our products and overarching process to address this very dilemma. It turns out that this problem—the need to be agile and to be error-free—is exactly the dilemma that needs to be solved.

Examination of the ISO26262 standard reveals that it requires more careful and more methodical development. Why? Because regardless of the competence of developers, they are human and they make mistakes. Collaboration amongst engineers with different areas of expertise, interpretation, ability and geography, leads to errors and inconsistencies.

But isn’t this a conflict with being agile? How can you follow the agile process and at the same time achieve all the details of the standard needed to be met? Hint—put intelligence into the machine and let it automate the result.

How We Got Here

SimuQuest’s history has actually been all about solving this problem. These two ideas may seem to be an irreconcilable dichotomy on the surface–but they don’t have to be. The solutions we develop fit in with the agile methodology and address the need to satisfy functional safety.

The beginning of SimuQuest arose from the belief that it’s not just about doing a good job of managing requirements or traceability. There are, in fact, a myriad of causes leading to inconsistency and they should be addressed, not through manual checking by the engineering team, but through automated intelligence.

My Personal Precursor

Early in my career (I was working at Motorola) when my team would put prototype hardware and software on the bench, it would rarely work the first time. Why? Well, because it was a prototype. The software, a rushed integration of prototype application functions and prototype BIOS components, was combined with prototype hardware. It was notorious for problems.

But this wasn’t just happening in a stand-alone lab with no context. On top of issues in the development process, there was pressure to deliver to the market to remain competitive. It’s understandable, and many of us have been there–you’re in a situation where management is bringing heat, the team has to work longer, and a lot of finger-pointing starts to happen between the different groups and stakeholders. Each issue may take days or weeks to resolve.

Plus, any errors that are not addressed could make their way into production.

Starting SimuQuest

Based on this experience, a set of us struck out with our own firm to solve this problem. We started with developing the QuantiPhi tool. The first big issue to address was the BIOS layer. QuantiPhi provided the intelligence to take these complicated microcontrollers and make sure the BIOS layer was now consistent. It worked. No longer would the software have to be hand-coded–a tedious, significantly error-prone process. We now had an automated solution that addressed the lower layer platform code. And there was no competitive tool that could do what QuantiPhi delivered.

But just as we had solved this problem, we were reminded that there are errors in other layers. We came to the realization that firms have multiple teams, spread across various locations, working on diverse project elements–and they are not integrated in one complete model.

And what about Agility? Well, when we started SimuQuest, we never liked this laborious process of hand-coding to try to resolve errors, especially for safety-critical products. The goal was always to be agile. In those days it was “agile” in a looser sense, but now there is a formal agile process. What came together, what we discovered and brought to fruition—was exactly what was being articulated by the engineering community as a formal agile process. We aggregated the tools to work within this approach and deliver absolute consistency in all layers of the software.

Addressing 26262 – UniPhi is Introduced

With the next tool we developed, UniPhi, we aimed to completely remove the possibility of inconsistency. Among the ISO 26262 needs that UniPhi addresses are elements such as Software Architecture Design and Software Integration and Testing.

To meet the ISO26262 requirements with the conventional approach, you would have to build, then test, then go back to fix–rinse and repeat (with manual error sprinkled generously throughout).

With UniPhi, errors are detected and resolved along the way as the intelligence of the machine automates this process. More specifically, UniPhi traces to approximately 50 statements within the ISO 26262 standard. Among these, we can identify numerous key features in UniPhi that directly support ISO 26262 including: hierarchical definitions of software architecture, data dictionary for interface management, support for configuration and calibration data, visualization of data flows between units/components and within units, requirements allocation and requirements coverage visualization, creation of integration test harness models, and built-in version control.

What does this mean? Absolute consistency in architecture, data and interfaces, complete transparency of projects, the elimination of error-prone development making its way to production–ensuring both Agility and Functional Safety while delivering confidence in production deliverables.

Are You Hamstrung by a False Orthodoxy?

But there is another obstacle that can get in the way. The UML/SysML versus Model-Based Design question.

In business, often a solution is proposed and marketed so well that it becomes the orthodoxy in the market. People embrace it and then become afraid to challenge it. In the embedded software world, particularly in automotive, there is an orthodoxy narrative around UML, SysML and AUTOSAR. The orthodoxy says these tools are a must. They are the tools that will guarantee the consistency you need.

But those tools are not solving the problems that we just talked about. They focus on designing software with these tools and not developing a system. We want to equip you to abstract away from software so you can design the system. So you are free to build it the way you want by giving you the ability to test, resolve errors automatically, and improve your logic iteratively along the way—fast. That’s what our tools do for you in the Model-Based Design environment. You shouldn’t have to worry about circling back and solving inconsistency issues. The intelligence in the machine will do that. We want to enable you to focus on innovation, not hamstring you with unnecessary process.

Could the Tail be Wagging the Dog?

This has happened in many areas of engineering. Let’s look at automotive. From the beginning, we wanted to control the car and the car’s engine. We wanted a system to be designed to do that. It’s an electronic system and inside the electronics system is a brain—the software. Because software is so error-prone, resolving software problems became an important task in the organization. So software managers became powerful influencers. They had a lot of power in the organization, and over time in some organizations, more influence than the systems people. But what the organization really needed was a system solution.

Now don’t get me wrong. Software is absolutely critical. But we believe that it should be serving the system.

It so happens our software colleagues came up with what we feel is a more laborious approach—UML/SysML—to solving the problem than is required. So, in response, within the Model-Based Design environment, we developed a human-centric solution with an elegant simplicity to it that supports developing a “top-town,” “big picture” systems solution.

The Clarion Call

If you’re just getting to meet us through this article, you’ll discover that we are excited to sound the clarion call for absolute consistency that can live inside the agile process and meet safety requirements. Our tools answer that call.

Don’t believe it can happen? We think a demo of our tools will make you a believer.

Of course, our goal is not to convince you, but to equip you to innovate and engineer the excellence that brought you into this line of work in the first place.

Send me an email. Let’s talk.

John Mills