Companies in regulated industries often struggle to get the functional safety team involved at the right stage of the development process.
When building complex products that must adhere to standards such as ISO 26262, IEC 61508, or DO-178C, for instance, too often the functional safety team gets looped in after the system is already designed and development has begun. And, by that point, it’s too late.
Real-World Implications
Imagine a company that uses Word documents to house multiple test cases defined using ID strings to refer to other artifacts like design or requirements.
When it comes time to review the test cases or adapt to changes in design, think of all the agonizing time the functional safety team will waste manually going through the list. Then consider the increased risk and quality issues should something being missed.
Time for Change
We’re at a pivotal point in defining when and where the functional safety team fits in a modern systems development process.
In a recent webinar, Jan Mauersberger, Lead Software Architect with our partner ANSYS, described the four roles of the functional safety team, as well as the negative effects of integrating the functional safety team too late in the development process:
Risk Assessments
This is done in order to know the criticality of failures in the system. The risk assessment results may imply more testing or development effort, and can have a big impact on both the timeline and cost of the project. Logically, the earlier this can take place, the better.
Safety Concepts
Typically, not a one-and-done solution, a safety analysis needs iterations and refinement – which may affect the design several times. The results of a safety analysis have to be visible early in order to react to the required changes.
Reliability Engineering
Dynamic formulas — based on industry standards and handbooks — calculate reliability data and have to be quickly adapted. If the functional safety team does not know of a change in design, for example, it can cause a lot of manual work.
Safety Management
The functional safety team has to compile and sign off on the safety case, and they are responsible for the product. Involvement and traceability from start to finish is essential for eliminating issues in safety, development and testing.
A Modern Approach
Today’s processes are iterative, with modifications introduced later and later. That’s why it’s recommended – and why most safety standards demand – that safety management and engineering start at the beginning of the development process.
The functional safety team can then mitigate issues early and stay connected throughout. It’s also critical that the team’s tools integrate with other solutions in the development process – without that, traceability is near impossible.
To learn more about the challenges of modern systems development in a regulated environment, watch our webinar with ANSYS. Plus, you’ll find out how the integration of Jama Connect and ANSYS medini analyze can help address these issues.
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
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?”
Amongst the powerful processors waving about onstage and videos projected on the walls of driverless cars navigating the streets of New Jersey, Jensen took pause in his address to put an emphasis on a word and concept not often used in the semiconductor industry: traceability.
The Tip of the Iceberg
To begin his segment on automotive functional safety, Jensen makes use of a common metaphor; saying, “Functionality is plenty challenging. The performance of these computers, the algorithms that have never been done before, the large-scale system integration with all different configurations of sensors is so complex, it is the most complex development we’ve ever done.
“And yet…”
In Jensen’s own words: “That’s just the tip of the iceberg.”
Beyond functionality, Jensen explains, “the most important feature of a self-driving car is not that it drives by itself; the most important feature is actually safety.” That is, how do you make a system respond safely, when the system itself fails?
This is clearly no easy achievement. In fact, Jensen argues it is so “extraordinarily complex” that it is literally easier to make a car drive by itself in the crowded streets of New Jersey than it is to ensure a system is functionally safe. After all, functionality is just the beginning.
From Culture, to Technology, to Tools
So, in the face of an engineering feat so “extraordinarily complex,” what do you do?
For NVIDIA, Jensen says, “it requires a holistic system approach, from culture, to technology, to tools.” This point is rather straightforward: to manage something so “extraordinarily complex” your entire organization needs be in unison, from the company culture to the tools by which your engineers use.
However, the next step in Jensen’s progression isn’t quite so black and white. With his own personal flair, Jensen announces, “We have the ability to achieve traceability for as long as we shall live.”
Hidden beneath this grandiose verbiage is a slightly ambiguous concept: traceability. Thankfully he continues, “If something were to happen, we can trace it all the way back to its source to improve and mitigate risk in the future.” Now we’re talking.
Achieving traceability means that everything throughout development — whether it be meeting minutes, email exchanges, specification tradeoffs, data sheets, management approvals, verification tests, you name it — is recorded, tracked in real-time and put to use to ensure that “if something were to happen,” or an error were to occur, you have the ability to immediately flag it, trace it to its source and fix the problem.
The question I then pose to you is, if something goes awry in your next highly complicated project, as you’re barreling a million miles an hour in the pursuit of your deadline, will your traceability help?
Complex development projects are a little like putting together a massive jigsaw puzzle: All the pieces are there, but sometimes how they fit together doesn’t become clear until real progress is already made.
The complexity is magnified when the project in question involves intricate microelectronics, software with billions of lines of code and hundreds of development teams who must work harmoniously to ensure functional safety standards are met. Not to mention hitting moving regulatory targets and the ever-present pressure to quickly deliver a complete, industry-compliant product to market.
We’re talking about a technology that not long ago was the stuff of science fiction; autonomous vehicles, systems for which code failure can lead to actual tragedy.
Bringing Teams (and Data) Together
When developing for a system with so many moving parts, every member of the development team using the same processes and platforms is a must to ensure safety compliance. To hedge against mistakes, teams must also be in sync, irrespective of core skill set or geography.
For companies whose businesses are based on constant innovation, getting all of these ducks in a row is a challenge.
As we detail at length in our recent paper, Driving Compliance with Functional Safety Standards, a Fortune 100 semiconductor company recently faced many of these hurdles, and deployed Jama Software to help clear them.
The semiconductor company knew this, and put together an integrated ALM solution supporting ISO 26262 compliance with Jama Software at its core.
Simplification as a Productivity Booster
Standardization of processes includes reducing oversized sets of tools and applications into a manageable roster of best-in-class solutions. Eliminating cumbersome or unnecessary apps enhances process efficiency for development teams at every stage.
The ALM solution they deployed enabled end-to-end requirements, functions, implementations and tests throughout the life-cycle process, as well as providing support for new functional safety and quality regulations, ensuring development teams can pass product audits and avoid costly delays due to rework.
The result was a well-oiled development machine. By hitting requirements the first time, the semiconductor company was able to accelerate its development cycles, delivering better finished products while achieving higher customer satisfaction.
Incorporating the proper toolsets to track development and document product safety compliance— a necessary step to avoid being buried by the challenges in a complex development project— further facilitated the process.
The standardization of toolsets and platforms meant that with each handoff on the developer chain, the teams could see their counterparts were all following processes as laid out by functional safety requirements.
Projects of this magnitude inherently put pressure on developers to keep their eye on the prize without being distracted by the countless shiny objects drifting across their line of sight. By simplifying processes, homing in on the best tools for the job and facilitating communication with partners and consortiums, development teams can tend to their own gardens.
When developing software for industries with rapidly changing regulatory environments, it’s critical that the platforms used are reliable, but also flexible and rigorous enough to remain compliant as requirements and standards evolve.
Of course, delivering a quality product that comports to current functional safety requirements quickly and efficiently is a big plus, which is why a Fortune 100 semiconductor company recently enlisted Jama Software to be at the core of its integrated application life-cycle management (ALM) solution.
With Jama’s help, this semiconductor company was able to completely transform its development process and streamline its operation, removing many obstacles to development along the way.
Putting Trust in Jama’s Proven Platform
Jama is certified by internationally recognized testing body TÜV SÜD for developing safety-related products to ISO 26262 (up to ASIL D) and IEC 61508 (up to SIL 3) standards. With such a rigorous development environment in place, the semiconductor company knew Jama’s platform would help it meet all necessary safety requirements.
Jama’s solution provides built-in attention to process, decision-making and change analysis in real time. Using actionable traceability, device-related developers and manufacturers, including semiconductors, can work faster without compromising on safety or quality. Jama provided the semiconductor company’s team with workflows for defining, building and testing automotive-related products that met their required functional safety standards.
Critically, Jama helps accelerate product design by enabling companies to reuse requirements across design teams and different generations of platforms — a critical part of the semiconductor company’s business strategy. The resulting integrated ALM solution brings together the best processes and tools, providing a single portal for accessing and analyzing a master data repository.
Standardizing processes and helping the semiconductor company reduce its massive toolset down to the most relevant ensured requirements were met the first time. This helped the company accelerate development cycles. And, at the same time, resulted in better end products and higher customer satisfaction.
Improving Processes Let Engineering Teams Focus on Engineering
The improved productivity and efficiency across teams and business units also reduced the overall cost of product development. Jama enabled teams to create a set of development-related assets once and reuse them across projects. This avoided the need to reinvent the wheel with each new iteration and reduced the likelihood of inconsistencies.
Effectively managing requirements also eliminated a large percentage of product defects. This saved time and money by detecting potential issues early — when issues are cheaper and easier to fix — rather than going back to the drawing board if they’re discovered too late in the game or in the finished product.
The resulting integrated ALM solution, with Jama at its core, seamlessly incorporated quality and compliance into existing workflows and best practices, when before it was a time-consuming, manual process. This enabled teams to spend more time engineering and less time fretting over compliance processes and documentation. Product are designed more efficiently and enter the market more quickly.
As autonomous vehicles sharing the nation’s roadways with driver-controlled cars moves closer to reality, a host of obvious safety concerns are being raised.
How will these cars react in the event of an imminent collision? How will they compensate for a sudden, unexpected lane departure? Ensuring passenger safety and reducing road fatalities will make or break this nascent technology, and software will be the brains behind it.
Self-driving car software must work correctly in any situation thrown at it, no matter how outlying. This fact presents unique challenges for developers charged with building and maintaining this complex software, as well as meeting new and changing compliance standards rolled out by regulatory bodies.
A Fortune 100 semiconductor company recently transformed its business relying on modern development solutions to manage and navigate the added complexity.
In Elaborate Systems, Efficient Communication is Key
It’s no small task building from scratch the software inside a car that will transport living, breathing humans on crowded roadways at high speeds. This means heavy collaboration on requirements is necessary to bring together experts of the various disciplines required for successful deployment. By bringing disparate groups together to communicate on requirement details and decisions, the semiconductor company ensured the right hand was always talking to the left.
To meet these challenges, software developers must strike a balance between functional safety and efficient, streamlined product development. We’re talking about billions of lines of code in self-driving vehicles, supporting complex microelectronics and software. The more complex a system, the more chances there are for errors, and in this case, the margin of error is virtually nil.
Overcoming challenges development teams face to ensure successful, timely deployment of their product while being flexible enough to adjust as regulations evolve is dependent on a common understanding of what’s being built and why.
Facing new ISO safety standards, the semiconductor company enlisted Jama Software’s development platform knowing it would help it meet its functional safety requirements.
Modern Tools Systematize Complex Challenges
This particular semiconductor company successfully incorporated standardized development processes and application lifecycle management (ALM) tools, which supported the development process from the initial planning stage through product retirement, tracking application changes along the way.
Modernizing their entire development process involved heavy standardization, so they honed in on a small set of best-in-class solutions from a sprawling list of more than 50 tools and applications.
To ensure development teams could pass product audits with minimal delay, the company also added support for new functional safety and quality regulations, avoiding the roadblocks associated with failures.
These same methods are necessary for other development teams looking to go to market with autonomous vehicle software that meets safety and product quality standards.
Equally important is ensuring disparate teams are working with the same compact set of tools, and carefully tracking every change and improvement along the way.
We may be a few years away from sharing the road with fully autonomous vehicles, but the work to ensure their safety and regulatory compliance is already well underway.
On today’s fast moving road to innovation requirements management can feel like a burdensome, yet necessary evil. For those of you who manage requirements with spreadsheets, word docs and power point, this process can feel even more unwieldy. Possibly worse? Using a heavy-handed tool like DOORS that adds extra overhead and requires additional skillsets for an already complex process. As products get smarter and connected, requirements management will only become more necessary. But it doesn’t need to be evil.
How? One way is by making sure everyone is working from the same, up-to-date information. Doing so lessens the burdens around requirements reviews. You can eliminate the waiting for the necessary stakeholders to provide input, or give approval. Teams can understand change as it happens, and analyze the up- or downstream impact of that change BEFORE change happens.
Why does it matter? The increased burden of regulations and compliance adds additional overhead to the product development process. Especially in the automotive industry where we are seeing rapid growth and leaps in innovation. Organizations who haven’t had to confront functional safety standards are having to learn regulatory standards, like ISO 26262, on the fly without missing deadlines or features to deliver on time for their customer.
Part of that additional overhead comes from how these teams are managing requirements and tracing validation & verification back to their requirements. Often times teams retroactively trace their data. With a solution like Jama you can pre-build your relationships, so traceability is automated, reducing the manual effort associated with building your traceability, and reducing your regulatory overhead in the process.
Bonus points for using a “fit for purpose” certified solution. A certified solution reduces the manual effort associated with validating your process for ISO 26262 Certification. As AFuzion CEO Vance Hilderman states: “Products labeled ‘safety-critical’ used to be a small niche, but today almost all devices are critical, with many requiring adherence to certification standards…We need to validate and qualify not just the software we build for our client but our development tools as well,” Read more about the Jama Validation and Software Compliance Kit.
In the end, the “old” way of working doesn’t fit the direction of the industry. Legacy tools and manual processes can’t keep up with market demands. You have too much to do to rely on an outdated way of working. If a modern requirements management solution can help you ease regulatory burdens by streamlining traceability, resulting in a more connected way of working that helps you understand the impact of change and can also provide a platform to shorten the requirements review process, isn’t that worth considering?
See Jama in action today! Check out our completely free 30-day Jama trial.
What do you call a system that has never-changing requirements? An obsolete system. Systems that are healthy and growing are always evolving or changing in some way.
Avionics, automotive and medical systems require airtight requirements. For the customers and users of these complex systems—and the companies building them—safety and security is critical.
Getting safety-critical requirements right is a surefire step in the right direction.
But too often, the requirements for these systems’ components invite more questions than they answer, and requirements management turns into a process of trying to pick out the bits of data you need, when you need them, while everything churns together in a roiling, boiling stew.
Safety-critical systems developers working with regulations and compliance standards know that opting for speed over safety, or safety over speed, adds risk. To succeed, both must be prioritized.
The majority of product, version and variant failures stem from weak requirements.
According to Vance Hilderman, CEO of the safety-critical systems and software engineering company AFuzion, “Safety-critical requirements include safety aspects, but not exclusively. There’s a grey area between functional, performance and safety requirements because if the system doesn’t function, it can’t be safe. If it doesn’t meet performance criteria it might not achieve safety aspects, but then there are explicit safety requirements as well. The problem is that most safety-critical requirement specifications are incomplete. They lack complete hazard-prevention mitigation. They can all be improved.”
“Almost all accidents related to software components in the past 20 years can be traced to flaws in the requirement specifications such as unhandled cases.” – Software Engineering, Safety-Critical Requirements & Specification
The challenge is to prevent those accidents in the first place and try to make tomorrow’s unhandled case be a handled case today. Knowing the right procedures for developing safety-critical requirements is the key. But what are these best practices, why are they the “best,” and how do teams utilize them? Vance offers some tips, below:
Good requirements should be mandatory. That means not a goal, not if you have time but truly mandatory.
Requirements must be consistent. Meaning, they don’t conflict with other requirements. Systems engineers must be able to manage and analyze requirements; with complex systems you need tools for that.
Requirements must be uniquely identified. They must state what we do, not how. The “how” is design and architecture.
Requirements need to be complete and unambiguous. That means full concurrence among developers as to what a requirement means, with no need for interpretation, because the requirement has sufficient detail to know exactly what the developer of that requirement intended.
Requirements must be consistent, with no conflicting characteristics. We know the priority, the timing aspects and we know the performance attributes. We cannot have conflicting logic. A or B, or A and B when C is not valid. We avoid different terms. For example, “trigger, assign, prompt, display, cue.” Those five words could be interchangeable but they’re different. We must be consistent.
Requirements must be traceable. That’s an essential part of good requirements management activities—to trace up to a system-level requirement and trace down to the implementation and the test. Traceability is also used during the code review to assess, “Does this logic fully implement all it should”?
Requirements must be testable. Each requirement is defined in quantifiable terms. For each requirement, can a test be formulated that will unambiguously answer the question, “Has the requirement been met?” Some things are that simple.
Requirements must be verifiable. For example, take this requirement, “The system shall support autonomous driving or flying.” All of us in the automotive world, we’re leaning towards that, from aviation to new AVs.
