Tag Archive for: Functional Safety

Functional Safety Compliance

In Part II of our six-part automotive series, our experts discuss how to ensure functional safety compliance using Jama Connect for Automotive. If you’re new to our Automotive Development blog series, you may want to go back and read Part I and the Series Intro

While safety has long been an important aspect of developing automotive systems, traditional safety considerations have largely involved mechanical systems. The modern automobiles, however, are increasingly relying on electronic systems and significant amounts of software.  This increase in electronics in vehicles brings in new considerations when it comes to functional safety compliance.

Note: Now that our automotive development blog series has concluded, you can go back and read series intro and Part I.

Functional Safety Compliance: ISO 26262

The standard that is concerned with the functional safety of electronic systems is ISO 26262. ISO 26262 is actually a series of standards that provides a framework for developing both electronic hardware and software systems where functional safety must be achieved. The standard describes a process for identifying risks in a system and provides guidance for mitigating those risk. The guidance is provided in the form of requirements and processes that are understood by the industry as the current state of the art for achieving functional safety.


RELATED: Watch a demonstration of the Jama Connect for Automotive Solution


A major component of ISO 26262 is a robust series of processes for requirements management and traceability. The processes require that organizations develop safety goals, translate those into functional requirements, technical requirements, and eventually both hardware and software requirements as appropriate for the system. The system must then be fully verified against all requirements and specifications. Critically, the processes require that traceability between the requirements, specifications, and verification activities be maintained and all documentation carefully reviewed.

Jama Connect for Automotive

A requirements management tool like Jama Connect for Automotive reduces the manual effort required in adhering to ISO 26262. Jama Connect for Automotive’s traceability features are ideally suited to maintaining and analyzing the required traceability. The review features are the ideal way to ensure documentation is fully reviewed and approved by a cross-functional team. The export features generate well-formatted documents for many of the work products required by ISO 26262.

The flow diagram below summarizes the ISO 26262 processes that can be managed in Jama Connect for Automotive. The boxes with an orange border represent the recommended work products to be captured in Jama Connect for Automotive. The boxes with a gray border represent the work products that benefit from being captured in Jama Connect for Automotive, but some organizations might choose to capture elsewhere.


RELATED: Learn more about the Jama Connect Functional Safety Kit for Automotive Teams 


High-Level ISO 26262 Process in Jama Connect for Automotive

Jama Connect for Automotive includes a fully functional framework that software teams can use to start getting value immediately. This includes complete documentation for how to complete each process most efficiently in Jama Connect for Automotive. Industry-specific Professional Services are also included to guide customers through the inevitable customizations needed by each organization. A complete list of the processes for working in Jama Connect for Automotive that align with ISO 26262 are listed in the table below.

ISO 26262 Alignment to Jama Connect Processes


To learn more about how Jama Connect for Automotive can help your team simplify compliance, streamline development, and speed time to market, download our solution overview.

Learn more about the Jama Connect Functional Safety Kit for Automotive Teams 

Jama Connect for AutomotiveToday we’re excited to introduce Jama Connect for Automotive, a new solution designed specifically to accelerate product development for automotive engineering teams in the autonomous, electric, and traditional vehicle space. This new solution is designed to assist engineering teams in improving development lifecycles and to better manage requirements, risk, hazard analysis, and test management, while simplifying alignment to safety-critical standards, including ISO 26262. 

The average life of vehicles on the road today exceeds 12 years, increasing the impact to the business of safety recalls and associated expenses to repair. Continued innovation in automotive product development, coupled with the need to meet safety-critical standards, creates a development environment where engineering teams must balance speed-to-market with product quality in support of functional safety standards. 

As the requirements management platform for six of the top 10 electric vehicle startups on the frontlines of innovation, we recognize these challenges and have been working closely with companies in the automotive industry to offer an all-in-one solution. Jama Connect for Automotive helps engineering teams get set up quickly, allowing them to focus on product design and innovation, while reducing the costs and effort required to align their development processes to functional safety standards. 

“Developers are balancing safety-critical standards and regulations with getting innovative products to market faster and in a highly disruptive and competitive climate,” said Josh Turpen, Chief Product Officer at Jama Software. “We’re excited to introduce our new solution designed specifically for automotive development teams, which will help facilitate the development process from the start. Jama Connect allows developers to hit the ground running with preconfigured templates and best practices built for automotive teams, saving critical time in the development process. This will be hugely beneficial for them especially now as teams continue to navigate the complexities of a remote work lifestyle.”  


RELATED: 5 Challenges in Automotive Product Development


Jama Connect for Automotive accelerates the development lifecycle with key features including: 

  • Automotive framework aligned to key industry standards and regulations: ISO 26262:2018, Automotive SPICE (ASPICE) and SEBoK 
  • Best practices including procedure and configuration guides for automotive manufacturing activities 
  • Document export templates including requirements specifications 
  • Functional safety kit with TÜV SÜD certificate and report 
  • Supply chain collaboration to enable an ongoing exchange of requirements between customers and suppliers 
  • Training and documentation aligned to automotive regulations, that provide accelerated onboarding to set developers up quickly   

The built-in templates and best practices guides provided in Jama Connect enable engineering teams to reduce development cycle times. Jama Software is helping to streamline development processes, ultimately accelerating new product launches to market while ensuring customers meet safety-critical standards and regulations for the highly evolving automotive industry.  


Register for our upcoming webinar with Ansys to learn more about bridging the gaps in safety-critical product development. 

REGISTER NOW

  

Safety Standard Compliance

Companies are facing immense pressure to deliver complex products to market faster while balancing rigorous safety standard compliance with standards like ISO 26262 in the automotive industry and DO-178C in aerospace.

Testing plays a key role in the successful development of safety-critical systems. However, many organizations still perform testing manually which can lead to the introduction of errors, inconsistencies in code analysis, delays in project timelines, and increased chances of recalls or failure to meet safety standard compliance.

Teams and managers need to feel audit-ready and confident they are meeting the objectives in these standards. Execution teams need the flexibility to work in their preferred tools to maintain efficiency. Striking the right balance is crucial.

On January 15th, we teamed up with Liverpool Data Research Associates (LDRA) for a webinar discussing how — through a direct integration between the Jama Connect™ and LDRA tool suites — organizations can better strike this balance.

Watch the full webinar here or read the highlights below.

 

Integrating Jama Connect & LDRA for Increased Confidence

Jama Connect makes it easy for teams to define, align, and execute on requirements (high level to low level), tests and other assets across the product development lifecycle. Jama Connect’s built-in traceability can help organizations identify coverage gaps in the product development process. Jama Connect’s Test Management Center supports workflows for manual testing enabling engineering and quality assurance teams to organize and execute requirements-based test plans and test cases to ensure quality and compliance. As products become more complex and automation becomes required, Jama Connect integrates to automated testing tools to support a cost-effective, scalable, and flexible solution

The LDRA tool suite specializes in automated software verification, including the analysis of standards compliance and of structural coverage. The LDRA tool suite can run unit tests, dynamic tests, and static code analysis on embedded software code used to power complex products and systems in regulated industries.

Automated Testing is now commonplace, not only in the unregulated software space, but in safety critical products and systems as well. Manual testing simply will not scale as products become more complex with embedded software. These automated tests and results of automated test runs need to be traced to requirements for compliance and safety reasons.

Through an integration between Jama Connect and LDRA, organizations can combine the strengths of a market leading, fit-for-purpose requirements management tool and a powerful, automated testing tool.

Driving Value

But why integrate? What value does this bring to organizations and teams?

Firstly, by integrating these tools, teams gain efficiency. This integration removes manual export/import processes that waste time and can lead to errors. The nature of the integration gives testing teams greater control over the movement of assets across tools and builds confidence in the overall compliance process.

Additionally, this integration strengthens traceability across tools. Requirements, tests, and test results are published in both tools. Traceability reports can be produced in both tools to review results and analyze system coverage. Teams can gain confidence that the entire system is covered, from requirements down to code.

Lastly, this integration eases the path to compliance and helps strike the balance between speed and safety. Improved efficiency through the integration lets teams work in their tools of choice and makes results available in both tools. Through strengthened traceability, teams will feel more “audit ready” and will help meet the objectives set in rigorous compliance standards like ISO 26262 and DO-178C.

To learn more about how the ISO 26262 standard impacts automotive development, download our white paper.

 

Creating a safety-first culture in complex product development

Today’s move-fast-get-it-to-market-yesterday product development culture puts a lot of pressure on companies to innovate quickly. Such circumstances can make defined processes and comprehensive documentation look unsexy and uncompetitive… even when they’re in the best interest of the organization.

In October, Jama Software and kVA by UL co-hosted a kVA Automotive Lunch & Learn at the Hyatt House in Silicon Valley. kVA by UL is a technical and management consulting group focused on functional safety and the ISO 26262 standard. Bill Taylor, Managing Director of kVA, spoke to a group made up primarily of automotive industry engineers, many of whom are working on autonomous vehicles.

Taylor presented on the topic of “Creating a Safety-First Culture in Automotive Development,” but the points he made could easily be applied to any complex product development where public and/or user safety are a primary concern. Here are five key take-aways from Taylor’s presentation.

Don’t Fall for the Smart Folks Fallacy

When we get on an airplane, do we trust that our pilot and co-pilot are experienced, well-trained professionals? Do we assume they really know what they’re doing and that they’ve done it many times before?

Of course, we do. So, why do the airlines — and the military, and every other aviation employer —make their pilots use checklists?

Learn how to mitigate common ISO 26262 mistakes with our whitepaper, “Top 15 ISO 26262 Snafus.”

It’s so they don’t have to think about it. The checklist is there so a distraction doesn’t cause the pilot to miss or forget a small but crucial step in their procedure.

But many who innovate for a living — especially those who face pressure to innovate rapidly — don’t like checklists. Checklists feel cumbersome, tedious, slow, and perhaps even antiquated. They’re constraining. They don’t let you work the way you want. Checklists force you to work to their dictates.

But checklists are great for safety, says Taylor. They force you to take all the prescribed steps.

Taylor warns against a phenomenon he sees often in the automotive and tech industries, which can roughly be described as the “Smart Folks Fallacy.” He describes it with a fictional conversation, which we’ll paraphrase:

“Hey, who’s keeping us safe?”

“Oh, don’t worry, we’ve got some smart folks over there.”

“Yeah, but how do we know we’re safe? Have we written good requirements? Have we analyzed them? Have we done direct testing? Do we have traceability throughout our process?”

“Nah, we haven’t done any of that. But those folks over there are really smart. So, we’ll be fine.”

Unfortunately, even smart people make mistakes. They’re under pressure to deliver. They get wrapped up in their immediate priorities. Even a smart person might miss something that’s tiny but critical.

Safety Relies on Process and Culture

Taylor says it’s hard to standardize culture. A true safety culture requires more than just following a set of rules, regulations, and standards. But a framework can be articulated.

In that framework, Taylor would expect to see a set of processes designed to comply with applicable safety standards. He would want to see process documentation that, among other things, describes:

  • The steps of the safety process
  • Any templates that are to be used
  • The tool set that will be used
  • Outputs that get reviewed, and who reviews them
  • The qualifications necessary to be a reviewer

Failure to follow a sound safety process leads to disaster, says Taylor. He maintains that in every accident report that makes the news, there is someone who says, in effect:

“I realized this could be a problem. I told my boss, and he kind of understood, but not exactly. Anyway, we were crazy busy, etc., etc.… It just got pushed aside.”

You need a system and a culture in place that will turn that potential problem into a documented safety anomaly — that will put it on the radar and make sure it gets addressed, says Taylor.

A Safety-First Culture Needs Police Officers

Just like governments need a police force to enforce laws, companies must invest in safety personnel with the authority to prevent potential hazards from being released into the field.

This doesn’t mean putting safety managers at the top of the pyramid, Taylor says. Instead, he likens it to Toyota’s famous quality system, where every plant worker has the authority to stop the production line if they spot a flaw. It’s a huge expense when it occurs, but it can save much greater expense down the line by avoiding costly recalls and lawsuits. It also makes everyone realize quality assurance is a part of their job.

It’s the same with safety. When a problem is a safety issue, the safety team must have the power to say, “Stop! We have a process to communicate and address this issue. We have the authority to make things stop until the issue is fully resolved.”

Learn how Jama Software worked with TÜV SÜD on our ISO 26262 certification process, and how you can lower the costs and risks of complying with functional safety standards, by watching our webinar.

Embrace the Idea of “Nothing Happening”

Taylor says safety engineers have a weird point of view: They’re inspired by the idea of nothing happening. That’s because, when people buy your product, they expect that nothing bad will happen to them… ever. If something bad does happen to them, and it’s your fault, they’re likely to sue you.

“Someone has to take ownership of this idea,” Taylor said. “There must be a group that says to themselves, ‘While the rest of the organization is innovating and creating amazing things, I’m going to make sure that nothing bad happens, and I can be motivated by that idea.’ It means you’re not out there making the thing be better and more awesome, you’re just trying to make it work in a way that doesn’t kill anyone.”

“And usually,” Taylor continued, “Your CEO says, ‘I thought it was just assumed that it wouldn’t kill anyone.’ And you say, ‘Yes, but someone has to be in charge of that. Someone needs to own that.’”

Accept that Safety is the Antithesis of Agile

While there are varying views on this topic, Taylor pointed out that a safety-first culture is the direct antithesis of the Agile development model.

The Manifesto for Agile Software Development values “individuals and interactions over processes and tools” and “working software over comprehensive documentation,” he said. Safety, on the other hand, cannot be assured without a commitment to process and documentation. “Software observed to be ‘working’ can often be fundamentally unsafe,” Taylor noted.

Taylor went on to say that where Agile tries to reduce friction, safety values friction. Friction is how we maintain control. Without friction, everything slips out of our hands.

“If our process has no friction, it’s out of control,” he said. “Agile is not wrong. Agile is wonderful for making progress” but it’s not sufficient for ensuring safety.

In complex product development, Taylor says, we don’t see a lack of smart people. What’s often lacking is a commitment to process and the tools that enforce that process.

We need to make allowances for Agile and a safety-first culture to coexist. Use Agile to make rapid progress. But allow safety to apply its processes — and apply the brakes, when necessary.

In other words, we need to accept the checks and balances of the safety process. Taylor summed it up this way: “Value friction. Value slowness. Take ownership of ensuring safety.”

To further assist in mitigating risks in the development process, maintaining compliance with automotive functional safety standards, creating a safety-first culture, and staying updated on the changes to ISO 26262, check out our white paper, “The Impact of ISO 26262 on Automotive Development.”

Autonomous Vehicles

Automakers continue to look toward the bright future of autonomous vehicles, but some are perhaps rightfully prioritizing safety over expediency.

GM originally planned to roll out thousands of self-driving electric cars this year through its subsidiary Cruise Automation. Those plans have been pushed out, however, as the company pursues further testing.

And while autonomous vehicle developers continue to put functional safety at the forefront of development, major players are also acknowledging that the public’s perception of the safety of driverless vehicles is critical. Recently, Waymo and AAA partnered to educate young people on the safety advantages of self-driving technology through its “Let’s Talk Self-Driving” program.

Meanwhile, ride-sharing companies Uber and Lyft continue to gradually roll out test vehicles in certain markets. Uber plans to begin testing self-driving cars in Dallas, Texas, in early November 2019, and Waymo intends to make up to ten Chrysler Pacifica self-driving cars available to Lyft users in Phoenix, Arizona.

One exception in the shift in the autonomous vehicle marketplace is Tesla. CEO Elon Musk continues to predict the arrival of full Level 5 automation by the end of 2020, but he’s never been one to fear going out on a limb.

Learn how Jama Software worked with TÜV SÜD on our ISO 26262 certification process, and how you can lower the costs and risks of complying with functional safety standards, by watching our webinar.

Autonomous Vehicle Technology Moving Freight

With 71% of US freight moved by truck and a persistent shortage of drivers, many in the trucking industry look forward to at least Level 2 and Level 3 technology improvements. Many Level 2 and Level 3 technologies simply improve features such as automated braking and lane guidance.

Increased automation could also mean greater efficiency. Truck drivers might be able to operate trucks for a longer period of time, and trucking companies can eventually save fuel and driver costs by “platooning” autonomous trucks

While questions still abound regarding the potential for autonomous vehicle technology impacting the job market for truck drivers, many in the industry welcome the coming automation. With a predicted driver shortage of up to 175,000 drivers by 2026, autonomous vehicle technology could help take the pressure off of a short-staffed industry.

Currently, Daimler, Tesla, and Volvo all have AV trucks and prototypes in development.

Learn more about ISO 26262 and automotive electronics development.

Other Applications of Autonomous Vehicle Technology

Even if fully automated, Level 5 autonomous vehicles are still some time away from deployment across the general population, autonomous vehicle technology is still advancing on a smaller scale.

Refraction AI, a Michigan start-up, aims to make food delivery services automatic with its three-wheeled REV-1 vehicle. The 4-foot tall, 32-inch wide robot is designed to operate in a bike lane at maximum speeds of about 12 mph.

Another startup, Starship Technologies, recently announced plans to expand its autonomous delivery service for food and groceries to 100 college campuses over the next two years.

Private sites show great promise for the growth of the autonomous vehicle industry. Planned communities, university campuses, and industrial and government sites have significant advantages for autonomous vehicle technology. The sites are smaller and easier to map and offer lower traffic densities and speed limits, making autonomous vehicle technology inherently safer.

Read our white paper about how one Fortune 100 semiconductor company is meeting the challenges of autonomous vehicle software safety with a compliance-ready solution that streamlines the development of products that adhere to relevant functional safety standards. Download: “Driving Compliance with Functional Safety Standards.”

 

avoid product recall with functional safety and risk management

While a positive brand reputation takes years to nurture and build, irrevocable damage to a brand — and a business — can happen in only moments.

As innovative companies are asked to move faster than ever to bring products to market, it’s worth taking a moment to step back and look at the cost — financial and otherwise — of a misstep that could lead to product recall or failure. In addition to fines, regulatory reprimands, and decreased market share, a product recall inevitably impacts your brand and can have a major impact on your bottom line.

Brand erosion, for instance, is one consequence of a major product recall. As the name suggests, brand erosion is the gradual destruction or diminution of your organization’s reputation when your products are deemed unsafe, unfit for the marketplace, or simply don’t perform as marketed.

If you’re working in an industry where functional safety is a top priority, like automotive or aerospace, guarding against these types of scenarios means getting crystal clear on the standards and regulations that help protect your product. That also means ensuring proper risk management techniques like Preliminary Hazard Analysis (PHA) and failure modes and effects analysis (FMEA) are being performed correctly.

Often times, penalties come as a result of companies not properly performing these functions, and instead rushing to deliver products that haven’t met benchmarks for quality, compliance, and — in the case of many industries — functional safety. Other times, companies simply fudge the data. Let’s look at a few famous examples:

Ford Motors’ 1980 Failure to Park Product Recall

While product recalls can happen in any industry, some of the most notorious and detrimental have happened to automotive companies. Such was the case for Ford Motors which, in 1980, was determined by the Department of Transportation to have more than 23 million cars and light trucks in circulation that contained a functional safety defect that permitted the vehicle to accidentally slip from park into reverse, although to the driver the placing of the shift lever appeared to be in park.

And while the company would have faced financial ruin if all 23 million automobiles had been recalled, regulatory authorities ruled that instead of recalling all vehicles involved, Ford could make amends by sending out a sticker for drivers to place on their dashboard warning that “unexpected and possibly sudden vehicle movement may occur” if the car was not properly parked.

The failed safety catch was found to have led to 6,000 accidents, 1,700 injuries, and 98 deaths, and Ford was tied up in litigation for years, costing the company tens of millions of dollars. The “failure to park” issues continued even after the sticker warning was issued.

While the cost of this functional safety error included lost revenue and expensive lawsuits, the safety malfunction may have additionally cost Ford the trust of their consumers. Especially in industries that are highly regulated — and thus highly trusted — recalls related to safety and reliability can cause devastating harm to the foundation of the organization.

Learn how how a Fortune 100 semiconductor company is meeting the challenges of developing automotive-related technology by downloading our case study.

Volkswagen’s “Defeat Device” Scandal

 While some product failures and recalls are the result of honest mistakes, such as the example above, others can be attributed to downright dishonesty. Such was the case for Volkswagen in September of 2015, when the company admitted that they had installed software in 550,000 automobiles that could figure out when the cars’ emissions were being tested and modify their performance to meet mandated standards.

Initially, Volkswagen spokespeople claimed that a “few software engineers” were struggling to meet stringent U.S. emissions standards while also producing a diesel engine that would perform well. That, the spokesperson said, was the reason those individuals decided to design a “defeat device,” a system to switch on emissions controls when the cars were being tested and turn them off when the automobile was driving normally. What we now know is that knowledge of this system went much higher, and some believe awareness could have been as high as the CEO, who resigned and was later indicted.

The scandal cost the company over $29 billion dollars in recalled automobiles, but the damages didn’t stop there. After losing the trust of the public, the company posted their first quarterly loss in 15 years, showing that consumers weren’t likely to invest their money in an organization that had deceived them.

A recent study by Edelman shows that consumers are more interested than ever in purchasing from organizations that they believe are “doing the right thing.” The study revealed that 64% of consumers around the world — up 13% from 2017 — now buy on belief, meaning that they will choose, switch, avoid, or outright boycott a brand based on where the organization stands on issues they care about.

The same study showed that consumer trust dropped 10% (from 58% to 48%) in the last year, and that nearly half of consumers don’t trust businesses to “do what is right.” And organizations whose products are recalled due to deceiving functionality are certainly not going to earn a reputation for doing what’s right for their customers.

An additional 8 million cars were sold in the E.U. with the same “defeat device,” but because emissions standards are much lower there than in the U.S., Volkswagen legally committed no crime in the E.U.

NASA’s Costly Math Mistake

On December 11th, 1998, NASA launched a robotic space probe called the Mars Climate Orbiter into space with the hope of studying the Martian climate, atmosphere, and surface changes. Nearly 10 months later, in September 1999, the $125 million probe burst into flames and fell to pieces in outer space. While this was certainly not the first, or last, failed space expedition, what sets this one apart is that the reason for failure comes down to a simple math error.

 The navigation team at the Jet Propulsion Laboratory (JPL) used the metric system of millimeters and meters in its calculations, while the team that designed and built the spacecraft, Lockheed Martin Astronautics in Denver, provided crucial acceleration data in the English system of inches, feet, and pounds.

The result was that the software controlling the orbiter’s thrusters was faulty. The software calculated the force that the thrusters needed to exert in pounds of force, while a second piece of code that read this data assumed it was in the metric unit— newtons per square meter. And while fortunately no lives were lost, this simple mistake pushed the orbiter dangerously close to the planet’s atmosphere, destroying the spaceship and killing the mission.

Despite NASA’s next Mars mission also resulting in a lost spaceship, the organization did bounce back from the ordeal. They recovered over the following years by returning to the basics, rebuilding the Mars program based on conservative strategies and concepts that had already been tried and tested.

In the case of NASA’s space mishap, detriment took the form of missed opportunity and lost ground in their research efforts. Because of the immense time, money, and resources it takes to launch a space mission, failures and missteps can result in years of setback. What was supposed to be the first weather observer in another world became a $125 million mistake.

Learn more about Jama’s Avionics Services by downloading our whitepaper. 

How Better Requirements and Risk Management Can Help You Avoid Product Recalls and Failure

Developing complex systems and products requires teams to have the ability to effectively define and track requirements, adhere to safety-critical regulations, collaborate and communicate effectively across teams and functions, and evaluate and mitigate potential risks. Failure to do so may result in product recalls or failure, and in the case of safety-critical products, injury or worse.

According to the CHAOS Reports from The Standish Group, three of the biggest contributors to projects that fail are lack of user input, incomplete requirements and specifications, and changing requirements and specifications.

Unfortunately, too many organizations struggle with requirements and risk management and the effects, some outlined above, can be devastating.

In the case of the Mars Climate Orbiter, the simple miscommunication between JPL and Lockheed Martin not only shows how small mistakes can lead to mission failure, but also highlights the need for teams — especially those in different physical locations — to work collaboratively instead of in silos, and for organizations to invest in solutions that help teams achieve this.

With the Jama Connect Risk Management Center, development teams can participate in risk management techniques including PHA and FMEA in accordance with industry-specific standards like ISO 14971 and IEC 60812. By working with live data, teams can efficiently identify and mitigate risks early in the development process, ensuring quality and safety in complex product development.

To learn more about how Jama helps organizations thrive in critical product markets by reducing risk and providing a single source of truth, download Frost & Sullivan’s recent executive brief,“Safeguarding Regulated Products Amidst Growing Complexity.”

Compliance standards, especially those that involve relatively new functional safety elements, will likely add additional requirements to the development process.

For example, the increasing complexity and abundance of automotive electronic systems led to the creation of a functional safety standard called ISO 26262 in 2011. And to ensure that new electronic functions remain functionally safe in the industry’s rapidly evolving environment, the International Organization for Standardization (ISO) recently introduced a second edition of ISO 26262 in December 2018. Similar regulations for other industries abound: DO-178B/C for aerospace standards, and IEC 60601 and ISO 14971 for medical standards.

Common to all of these safety standards is a risk-based approach to determine the criticality and potential hazards associated with key system functions. The primary goal of these standards is to prevent the failure of a system or device that could cause injury, harm or death. If a failure is unavoidable, then the system should fail gracefully.

Watch our webinar: “Understanding ISO 26262 Compliance for Automotive Suppliers”

The Impact of Tools in Functional Safety

ISO 26262 complements good systems engineering practices by requiring that hardware and software safety concerns be addressed and documented in a systematic way throughout the development lifecycle. In the past, safety design was considered part of general requirements activity. But merely identifying and tracing requirements in the software and hardware teams is not enough. The common practice of hardware and software teams working in silos will not guarantee the level of safety coverage required by ISO 26262.

How can the problem be resolved?

One of the key things missing from the general approach to requirements are the traceability links between phases. Many tools do a great job of requirements management and traceability within a particular phase but provide a poor auditable trail for traceability between phases. The activities of comprehensive and complete lifecycle traceability become an auditing afterthought, to be finished after the project is completed. This is the result that ISO 26262 tries to avoid through documented attention to the development process, decision-making and selection of supporting tools.

And because functional safety is a top priority for so many of our customers, Jama went through the process of earning a certification from internationally recognized testing body TÜV SÜD. Jama Connect™ is certified as a fit-for-purpose software tool for development of safety-related products according to ISO 26262 (up to ASIL D), IEC 61508 (up to SIL 3), IEC 62304 and EN 50128, giving our customers confidence that the products they are building are safe to use.

Learn more about ISO 26262 and automotive electronics development.

Tool Implementation Strategies

Tool qualification depends upon how the tool is used, which in turn determines what impact it could have on safety. For example, depending upon its usage, can the tool introduce a hardware defect or software bug into the system? How the tool is used within a tool chain will also determine the probability that an error introduced by the tool will be detected.

A confidence level is assigned to a given tool, or a flow within a tool, based upon the probability that it will insert or cause an error, combined with the likelihood that the error will be detected during the development process. The importance of the tool confidence level is that it will determine the cost an organization must invest in tool qualification.

As with other standards, implementing the ISO 26262 process requires iteration of a number of basic steps:

  1. Determine the existing process and tools to answer the question “Where are we now?”: Review the current embedded hardware and software development processes and tool chains. Understand the application(s) to be developed and assign levels of confidence in terms of safety.
  2. Gap analysis to answer the question “Where would we like to be?”: Perform a gap or impact analysis to identify current challenges and process efficiency improvements – often done using model-based design techniques.
  3. Training and instruction: Provide design-for-safety training and instruction to address the previously identified gaps.
  4. Hands-on deployment support: Apply the knowledge gained in the previous steps to a specific pilot project. This will require assistance in a wide range of areas including requirements traceability, modeling, simulation, code generation, verification, validation, tool qualification and system integration.

Jama Software is the first SaaS and Agile vendor to be ISO 26262 fit-for-purpose certified by TÜV SÜD. Read more.

Alignment with Best Practices for Functional Safety

This holistic approach to functional safety exemplifies several key elements of good system engineering processes: collaboration, traceability, validation and verification (V&V), risk analysis and mitigation, and careful integration within the tool chain.

Watch our webinar, “Jama ISO 26262 Certification and Best Practices for Development,” to learn more about how teams creating products for any safety-critical industry can lower the costs and risks of complying with functional safety standards.

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

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?”

During a keynote at CES 2018 in Las Vegas Nevada, NVIDIA’s Founder and CEO, Jensen Huang, took the stage in his iconic black leather bomber jacket. As expected, he touched on all things NVIDIA: from new gaming technology to their recently announced autonomous driving platform, DRIVE.

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?

I know Jensen’s will.

To see how Jama’s solution helps companies achieve traceability, read our paper, “How Traceability Makes Semiconductor Development Easier” or get in touch