In this blog, we recap sections from our eBook, “IEC 61508 Overview: The Complete Guide for Functional Safety in Industrial Manufacturing” – Click HERE to read the entire eBook.
Functional Safety Made Simple: A Guide to IEC 61508 for Manufacturing
What Is IEC 61508?
As discussed previously, industrial manufacturing firms need to prevent dangerous failures that may occur with the use of their system. The challenge is that oftentimes systems are incredibly complex with many interdependencies, making it difficult to fully identify every potential safety risk.
Systematic or random failure of hardware or software
Human error
Environmental interference, such as temperature, weather, and more
Loss of electrical supply or other system disturbance
Incorrect system specifications in hardware or software
IEC 61508 creates requirements to ensure that systems are designed, implemented, operated, and maintained at the safety level required to mitigate the most dangerous risks. The international standard is used by a wide range of manufacturers, system engineers, designers, and industrial companies, and others that are audited based on compliance. The standard applies to safety-critical products including electrical, electronic, and programmable-related systems.
Why Was IEC 61508 Developed?
The primary goal of the standard is human safety, and it’s based on a couple of principles, including:
Use of a safety lifecycle. The lifecycle outlines the best practices around identifying risks and mitigating potential design errors.
Probable failure exercises. This assumes that if a device does fail, a “fail-safe” plan is needed.
IEC 61508 applies to all industries; however, even though it covers a broad range of sectors, every industry has its own nuances. As a result, many have developed their own standards based on IEC 61508.
Industry-specific functional safety standards include ones for:
Industrial – IEC 61496-1, IEC 61131-6, ISO 13849, IEC 61800-5-2, ISO 13850, IEC 62061, IEC 62061, ISO 10218
Transportation – EN 5012x, ISO 26262, ISO 25119, ISO 15998
Buildings – EN/ 81/ EN 115
Medical devices – IEC 60601, IEC 62304
Household appliances – IEC 60335, IEC 60730
Energy systems and providers – IEC 62109, IEC 61513, IEC 50156, IEC 61511
The standard includes Safety Integrity Levels (SILs), which cover four stages from SIL 1 to SIL 4 and indicate whether a safety function is likely to result in a dangerous failure.
The IEC 61508 standard covers the most common hazards that could occur in the event of a failure. The goal of the standard is to mitigate or reduce failure risk to a specific tolerance level. The standard includes a lifecycle with 16 phases, broken into seven parts, including:
Part 1: General requirements
Part 2: Requirements for electric, electric programmable safety-relevant systems
Part 3: Software requirements
Part 4: Abbreviations and definitions
Part 5: Examples and methods to determine the appropriate safety integrity levels
Part 6: Guidelines on how to apply Part 2 and Part 3 Part 7: An overview of techniques and measures
The first three parts highlight the standard’s requirements, and the rest explain the guidelines and provide examples of development.
IEC 61508 Certification: Is it Required?
IEC 61508 certification is optional in most cases, unless you contract with a firm that requires it, or it’s required by your local government. Even if it’s not mandatory, achieving certification provides peace of mind and creates a clear path to improving safety. Certification is offered through international agencies specializing in IEC 61508, such as the TÜV SÜD. Completing certification provides creditability around your IEC 61508 compliance and is a point of differentiation if bidding on a contract against multiple contractors.
Understanding functional safety requires a hazard analysis and risk assessment of the equipment under control (EUC).
The hazard analysis identifies all possible hazards of a product, process, or application. This will determine the functional safety requirements to meet a particular safety standard.
A risk assessment is needed for every hazard that you identify. The risk assessment will evaluate the frequency and likelihood of that hazard occurring, as well as the potential consequences if it does happen.
The risk assessment determines the appropriate SIL level, and you can then use either qualitative or quantitative analysis to assess the risk. The guidelines don’t require a specific method of analysis, so use whatever method you prefer.
https://www.jamasoftware.com/media/2023/05/2023-05-09-functional-safety-made-simple-1.jpg5121024Steven Meadows/media/jama-logo-primary.svgSteven Meadows2023-05-09 03:00:452023-06-22 15:26:51Functional Safety Made Simple: A Guide to IEC 61508 for Manufacturing
As we enter 2023, Jama Software® asked selected thought leaders – both internal Jama Software employees and our external partners – across various industries for the trends and events they foresee unfolding over the next year and beyond.
In the third part of our five-part series, we asked Beau-Colby Thomson – Associate Account Executive at Jama Software – Vlad Tanasescu – Global Industrial Sales Lead at Jama Software – and Steven Meadows – Principal Solutions Lead at Jama Software – to weigh in on Industrial and Consumer Electronics (ICE) product and systems development trends they’re anticipating in 2023.
2023 Predictions for Industrial and Consumer Electronics Product Development
What product, systems, and software development trends are you expecting to take shape in 2023 as it pertains to the ICE industry?
Beau-Colby Thomson: Industrial robotics and automation adoption will continue to grow at a rapid pace to combat labor shortages and growing product demand.
Industrial Internet of Things (IIoT) + edge computing use cases are growing year over year. This will introduce complex software development to product lines that historically may have been mostly hardware + firmware. The addition of a new discipline into product development organizations may result in disruptions to existing processes.
Energy Storage continues to be an area of focus for the world. As more utility infrastructures fail and the cost of renewable energy decreases, the demand for energy storage systems will grow.
Fusion/Fission/Nuclear is becoming more widely accepted (more so in Europe than in North America). The development of these products takes many years at a time to complete, however the headcount of the engineering organizations for these companies continues to grow now.
Steven Meadows: The Internet of Things (IoT) continues to become more prevalent across all industries. Everyday consumer electronics like laptops, home appliances, and tablets are manufactured with an increasing number of sensors and inputs that transfer data to different networks and applications. Improved remote monitoring of these systems can also be enabled through IoT helping customers to maintain their products with ease.
Cloud computing also continues to grow across the software industry. Cloud is becoming the golden standard allowing for more flexible, cheaper, and sustainable solutions. Companies increasingly rely on cloud computing for projects and daily activities, without the need for managing system administration, upgrades, and security.
DevOps is constantly evolving with more companies utilizing a unified software development approach, allowing for code to be delivered faster with improved quality. This means there is less time spent on the integration of teams, infrastructure management, and the deployment of code. Product managers continue to push for the implementation of DevOps, finding it critical to deliver their products at a lower cost, and with better quality outcomes.
Vlad Tanasescu:
Robotics: autonomous factories, warehouse and delivery robots, AgriRobots (agriculture), humanoids.
In terms of product and systems development, what do you think will remain the same over the next decade? What will change?
Thomson: The increasing level of connected products will drive more systems development maturity in organizations that fall under Industrial, Consumer Electronics, and Energy (ICE).
I believe over the next decade the struggle with writing ”good” requirements will not change.
Tanasescu:What will remain the same?
More software (SW) in systems, intelligence and autonomy in systems.
More autonomy.
Focus on smart / green energy (wind farms, etc.)
Innovation within roboticsand IoT.
What will change?
Functional Safety will become more important for industrial products.
New regulations will be introduced for robots as the technology evolves.
Meadows: Product development companies will continue to invest heavily in digital platforms which will help to streamline their processes, improve quality of their products, and improve team collaboration. Excel and Word are antiquated solutions that do not give product teams the necessary capabilities to handle complex development, so requirement solutions and Application Lifecycle Management (ALM) tools will continue to see an uptick in investment going forward.
There will continue to be an emphasis placed on functional safety with the functional safety devices market set to hit $10 billion by 2030. This means teams will need to prioritize functional safety throughout their development process to ensure that products are safe for industrial or private use. Development companies will continue to invest in the certification of their products, conforming to functional safety standards such as IEC 61508. This gives vendors and customers increased confidence in the overall quality of their manufactured systems.
How do you foresee regulations shifting in ICE product and Systems Development over the next decade?
Thomson: We will definitely see more safety regulations imposed as products are introduced to the real world and unforeseen risks occur. I believe these will be both safety and cybersecurity related regulations.
This is mostly for automated technologies and energy products, potentially cybersecurity for connected consumer tech or IIOT applications.
Tanasescu: More dedicated FuSa (functional safety) standard will appear for robots, IoT devices, and autonomous systems as these technologies become more embedded in society.
Requirements engineering, traceability, risk analysis will become increasingly important.
Any major disruptions to the ICE product and systems development industry you’re anticipating in 2023?
Thomson: The predicted recession may have an impact on consumer spending therefore consumer technology development. Companies may also be reducing funding to innovative R&D or incubation projects.
Tanasescu: I’m not sure about 2023, but I believe that over the next 10 years the robotics sector will grow exponentially.
Over the next years the traditional home appliance manufacturers will need to become IoT companies and focus on connected devices.
What sorts of process adjustments do you think development teams will need to make to be successful in 2023?
Thomson: Standardization & maturity.
Tanasescu: Work as agile as possible, even in regulated fields, while maintaining engineering rigor. Embrace a best-of-breed tooling approach. Enable collaboration across many global stakeholders.
What do you think will be some of the differentiators between a company surviving to see 2030, and those that do not?
Thomson: The ability to achieve executive initiatives to get products to market quicker while minimizing defects found after launch
Tanasescu: Investment in engineering. Understanding the value of structure and measurable product definition. Understanding of the future trends and the importance of software driven & connected devices, autonomous systems and digitalization.
Meadows: Development companies need to embrace a proactive approach to safety and quality when developing their systems. By incorporating functional safety throughout the product lifecycle, companies are much more likely to release safe and market leading products. These companies, and their customers, will experience greater long-term benefits than those companies that manage their safety and quality processes reactively.
By educating development teams on how to define requirements from the stakeholder level down to component, companies will have a better chance of building exactly what they intend to. By incorporating AI to help with requirements definition, teams can gain a competitive edge and author requirements in a concise and meaningful way.
What advice would you give to new companies entering the ICE industry?
Thomson: Build your house on bricks, not sticks. Leverage as much outside expertise/tools and focus your engineer’s efforts on innovation.
Tanasescu: Start with a structured, process driven approach when it comes to the use of development tools and traceability processes early on to best enable scale across the development programs, as the business will grow.
Meadows: When entering the industrial and consumers electronics industry, there are a lot of areas to consider when it comes to product development. Primarily, new companies should educate themselves on applicable standards and product development best practices. They should also consider certification in different areas including functional safety to make their products more marketable across a broader range of geographies and customer profiles.
What topic(s) do you wish companies were paying more attention to?
Thomson: It would be ideal if companies analyzed their engineering deficiencies and understood the amount of capital that gets wasted money in product development.
Tanasescu: Engineering predictability. Advantages of using a best –of-breed toolchain.
Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2023 approaches?
Thomson: Hopefully as an integral part of the best of breed landscape. The biggest expectation we can point our customers towards is our ability to measure project health through traceability and requirement scores.
Tanasescu: Jama Software will continue accelerating the time to market efforts of ICE companies, make development more predictable and measure product development efficiency. Jama Connect® will keep enabling ICE innovators to succeed globally. I see Jama Connect as an expert in complex requirements engineering, traceability in systems engineering which serves its customers as a trusted innovation partner.
Our customers can expect continuous investment in and commitment to our product and ICE industry solutions.
Meadows: As systems become more complex with increased connectivity between interfaces and networks, the need for a best-in-breed product development platform that enables Live Traceability™ is critical. Gone are the days when teams could get by documenting requirements, tests, and risks in Excel and Word.
To speed time to market, produce better and safer products, teams need to adopt digital solutions, giving them a competitive advantage. Jama Software continues to invest heavily in its core platform, Jama Connect. We have been incorporating AI capabilities to improve requirements authoring, enhancing integration options with other best in breed applications and always bringing out new capabilities to support the development of some of the most complex devices on the market today.
https://www.jamasoftware.com/media/2022/12/2022-12-15-2023-v2-predictions-industrial-1.jpg5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-12-15 03:00:472023-01-12 16:46:032023 Predictions for Industrial and Consumer Electronics Product Development
In part two of our blog series, we cover the second half of our eBook, “A Guide to Road Vehicle Cybersecurity According to ISO 21434” – Click HERE for part one.
Much like other automotive standards, ISO 21434 defines a system engineering V-model to be followed for the development of cybersecurity features.
Concept Development
The cybersecurity V-model starts with the definition of the exact “item” that will be developed. The item is a component or set of components that implement functionality at the vehicle level and is defined in an item definition. In many cases, the same item definition may be used for both functional safety analysis and cybersecurity analysis.
Once the item has been clearly defined, a Threat Analysis and Risk Assessment (TARA) is performed to identify what cybersecurity threats exist for the item and what the risk of those threats are. For threats where the risk must be reduced, concept level requirements are developed, known as cybersecurity goals. Cybersecurity goals form the highest-level requirements for the system being developed from a cybersecurity perspective. For risks that will remain after cybersecurity goals are achieved, cybersecurity claims are documented to explain what, if any, risks still exist and why they can be accepted.
After defining cybersecurity goals, a cybersecurity concept is created. This documents the high-level concept that will be used to achieve the cybersecurity goals. The concept takes the form of cybersecurity requirements as well as requirements on the operating environment.
Product Development
Once a cybersecurity concept has been developed, the system must be designed in a way that will satisfy the cybersecurity requirements. Any existing architecture must be updated to consider the cybersecurity requirements. Each component of the system should be designed to support the cybersecurity requirements.
Although ISO 21434 provides an example of developing a system in two layers of abstraction, no specific number of layers is required. Instead, the standard leaves it to the product development organization to define a process appropriate for the complexity of their system. This ensures that organizations can adapt the standard to a wide range of systems and, for many, means that their existing system engineering process will satisfy ISO 21434.
Once the components of the system have been designed and integrated, the system must be verified to ensure that it meets the cybersecurity requirements.
The methods for verifying the system can include:
Requirements-based testing
Interface testing
Resource usage evaluation
Verification of the control flow and data flow
Dynamic analysis
Static analysis
The integration and verification activities should be documented in a verification specification and the results of verification documented in a verification report.
Validation of Cybersecurity Goals
While the focus of verification is ensuring that the item meets the cybersecurity requirements, validation ensures that the item achieves the cybersecurity goals. This is done by first validating that the cybersecurity goals are adequate and then validating that the item achieves the cybersecurity goals. Validation may involve reviewing work products, performing penetration testing and reviewing all the managed risks previously identified. A rationale for the validation activities is required. The completed validation is documented in a validation report.
Even after product development is complete, the cybersecurity lifecycle continues.
Production
During the production phase, the item that has been developed is manufactured and assembled. A production control plan is required to ensure that cybersecurity requirements for post-development that were identified earlier in the lifecycle are applied to ensure that no vulnerabilities are introduced during production.
Operations and maintenance
Once an item has been integrated into a vehicle and the vehicle is on the road, new cybersecurity threats can still be identified. ISO 21434 requires organizations to have a plan for how to respond to this scenario.
Organizations must create a cybersecurity incident response plan each time a new cybersecurity incident occurs. This plan includes what remedial actions are required and how they will be performed. The response may range from providing new information to vehicle owners, to over-the-air updates, to recalls where the owner must bring the vehicle in for service.
End of cybersecurity support and decommissioning
Given that the cybersecurity lifecycle continues after vehicles have been sold to consumers, a method for ending cybersecurity support for those vehicles is needed. ISO 21434 focuses on developing a plan for communicating with customers when cybersecurity support ends. Since decommissioning can occur without the organization’s knowledge and in such a way that decommissioning procedures cannot be enforced, ISO 21434 only requires making documentation available to explain how to decommission the item with regards to cybersecurity, if this is even required.
Integrating the Cybersecurity with Overall System Engineering
ISO 21434 defines many cybersecurity-specific requirements and requires personnel with specific cybersecurity knowledge and skills. Because of this, it may be tempting for organizations to silo cybersecurity engineering activities from other engineering activities, but this would be a mistake. While risk analysis required by ISO 21434 can be considered as a separate activity from other system engineering activities, a single product still must be developed that meets a wide range of requirements, including cybersecurity requirements. For this reason, it is best to manage a unified database for requirements, architecture, and design, rather than tracking cybersecurity artifacts separate from others.
To support this, think of cybersecurity analysis as another input to product development, just like functional safety analysis and market analysis.
By taking a unified approach, a single system engineering V-model can be implemented that describes an overall product development process that incorporates cybersecurity without creating silos. While specialists will be focused on performing cybersecurity analysis, implementing known best practices and validating the final system achieves cybersecurity, this must be done in cooperation and coordination with the rest of product development.
How Jama Connect® Supports Cybersecurity Engineering
One way to implement a unified requirements, architecture, and design database is by using Jama Connect®. Jama Connect for Automotive provides a framework that incorporates the key requirements of ISO 21434 into a single project structure along with overall system engineering.
Specifically, Jama Connect for Automotive provides guidance on supporting the following activities:
TARA Cybersecurity goals
Cybersecurity concept
Design Integration and verification
Validation
An example of the framework is shown below:
Conclusion
ISO 21434 introduces a robust framework for organizations to apply the state-of-the-art in cybersecurity to their product development. This framework is necessary from both a market and regulatory perspective. The high-level of connectivity available in vehicles today means that there many ways for someone to maliciously change a vehicle’s operation. While many consumers may be unaware of the risks today, if there are ever accidents that result from cyber-attacks, that will change quickly. A vehicle OEM’s brand will surely be impacted by such as incident. In addition, regulators have already imposed strong cybersecurity requirements in many regions. ISO 21434 is quickly becoming an essential regulation for companies developing products at all levels of the automotive supply chain.
Whether your team is young or seasoned, small, or large, all together or scattered across boundaries, Jama Connect for Automotive can help improve processes, reduce costs, improve time to market, and help achieve ASPICE compliance. To learn more about Jama Connect for Automotive, download our datasheet.
Interested in learning more about how Jama Connect for Automotive can help provide your team meet market demands more quickly and efficiently?
Thank you for reading the conclusion of this 2 part blog series. To read the entire eBook, click HERE.
https://www.jamasoftware.com/media/2022/12/2022-12-13-guide-to-road-vehicle-cybersecurity-part-2-1.jpg5121024McKenzie Jonsson/media/jama-logo-primary.svgMcKenzie Jonsson2022-12-13 03:00:592023-01-12 16:46:04A Guide to Road Vehicle Cybersecurity: Part 2
In part 1 of this 2 part blog series, we overview our eBook, “A Guide to Road Vehicle Cybersecurity According to ISO 21434” – We will link to part 2 here when it publishes.
As the automotive industry becomes more complex and more connected, cybersecurity is emerging as a major concern, and therefore a priority for development teams.
One standard, in particular, has been developed to address cybersecurity risks in the design and development of car electronics — ISO SAE 21434 “Road vehicles — Cybersecurity Engineering.”
In this guide, we cover:
An overview of ISO SAE 21434
The urgency behind automotive cybersecurity
How Jama Connect® supports cybersecurity engineering
Introduction
As the automotive industry becomes more complex, and more connected, cybersecurity is emerging as a major concern, and therefore priority, for development teams.
While vehicles have been traditionally isolated systems that had to be physically accessed to tamper with, increasingly, more and more vehicles include wireless connectivity. According to Juniper Research, the number of vehicles with wireless connectivity will rise from 110 million in 2020 to an excess of 200 million by 2025. These vehicles pose a much greater cybersecurity risk than previous designs.
One standard in particular has been developed to address cybersecurity risks in the design and development of car electronics – ISO SAE 21434 “Road vehicles — Cybersecurity Engineering.”
In this guide, we will examine this important automotive cybersecurity standard, how it is impacting automotive development, and lastly how Jama Software® can help.
What is Automotive Cybersecurity?
Cybersecurity, within the context of road vehicles, is the protection of automotive electronic systems, communication networks, control algorithms, software, users, and underlying data from malicious attacks, damage, unauthorized access, or manipulation.
What is ISO 21434?
Regarded as one of the most comprehensive approaches to connected vehicle cybersecurity, ISO 21434 specifies engineering requirements for cybersecurity risk management regarding concept, product development, production, operation, maintenance, and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces.
This standard supports the implementation of a Cybersecurity Management System (CSMS).
The first edition of ISO 21434 was published in 2021 and automotive suppliers and OEMs should strongly consider integrating ISO 21434 into their current process.
What is a Cybersecurity Management System (CSMS)?
A Cybersecurity Management System is a systematic risk-based approach defining organizational rules and processes, security policies, resources, and responsibilities to manage risk associated with cyber threats to vehicle road users and protect them from cyber-attacks.
ISO 21434 provides vocabulary, objectives, requirements, and guidelines for cybersecurity engineering in the context of electrical and electronic systems within road vehicles. The goal of the standard is to enable the engineering of electrical and electronic systems to keep up with the state-of-the-art technology and evolving cybersecurity attack methods. Adhering to the standard will allow organizations to define cybersecurity policies and processes, develop a cybersecurity culture, and manage cybersecurity risk.
The structure of the standard is as follows:
14 clauses, 11 are normative
Similar structure and vocabulary as ISO 26262
Each clause has at least one requirement and one work product
Some clauses have RC (recommendations), and PC (permissions)
Nine informative appendixes
Terminology
To achieve the goal of a common vocabulary within cybersecurity engineering for road vehicles, ISO 21434 defines a number of terms.
Asset: A part of an item that has cybersecurity properties (ex: OBD II port, safety requirements)
Attack Path: A series of steps that an intruder could use to compromise an asset
Cybersecurity Goal: Top level product requirement resulting from the TARA (see below for TARA definition)
Cybersecurity Claim: An identified risk that will be accepted, typically mitigated by liability transfer
Cybersecurity Concept: Cybersecurity requirements on the item and operating environment that implement controls to protect against threats
Damage Scenario: The potential damage to a road user caused by the realization of a threat scenario
Item: A component or a set of components that implements a function at the vehicle level. Could be identical to the functional safety item
TARA: Threat and Risk Assessment. Assets with cybersecurity properties are identified and damage scenarios are identified if the asset is compromised. Threat scenarios are identified and supported with attack paths. Risk values are assigned, and cybersecurity goals are established for unacceptable risk
Threat Scenario: Potential cause of the compromise of the cybersecurity properties of one or more assets that leads to a damage scenario
Lifecycle
ISO 21434 defines a cybersecurity lifecycle that starts with the definition of a new vehicle system and ends with that vehicle system being decommissioned or support by the OEM ending.
This means that cybersecurity activities continue after a system is put into production to ensure that new vulnerabilities that are discovered after a system enters production are still identified and mitigations added if necessary.
ISO 21434 defines requirements for an entire organization developing automotive systems to ensure that the necessary cybersecurity governance and culture are in place to support cybersecurity engineering. This includes ensuring that the organization acknowledges that there are cybersecurity risks, executive management is committed to the management of the risks, and that the organization has defined rules and processes to implement the requirements of ISO 21434.
In addition, the organization must have personnel in cybersecurity roles that are competent, policies that define how information can be shared both internally and externally, an appropriate quality management system, management of all product development tools, and robust information security. Audits must be performed to ensure that the organization achieves the objectives.
Project-Specific
Each project that develops or updates a road vehicle system or component must manage the cybersecurity engineering activities specific to that project. This includes the following considerations:
a) Assigning the responsibilities regarding the project’s cybersecurity activities to specific individuals
b) Planning the cybersecurity activities that will be performed during the project
c) Creating a cybersecurity case that provides the argument for the cybersecurity of the system or component
d) Performing a cybersecurity assessment if the project risks deem it necessary
e) A decision of whether the system or component can be released for post-development from a cybersecurity perspective.
Thank you for reading part 1 of this 2 part blog series. We will link to part 2 here when it publishes.
https://www.jamasoftware.com/media/2022/12/2022-12-06-guide-to-road-vehicle-cybersecurity-1.jpg5121024McKenzie Jonsson/media/jama-logo-primary.svgMcKenzie Jonsson2022-12-06 03:00:052023-01-12 16:46:06A Guide to Road Vehicle Cybersecurity: Part 1
How EN 50128 Establishes Functional Safety Standards for Railway Software
In increasingly complex, rapidly evolving, and highly regulated industries, product development teams must build safety-critical products, while streamlining risk management and keeping accuracy and security at the forefront. This blog post will define functional safety and EN 50128 and explain why compliance with safety standards is critical to railway software and industrial manufacturing teams.
What is Functional Safety?
As part of the overall safety of a system or piece of equipment, functional safety is a key component that builds upon automatic protection. The best way to reduce risks in industrial manufacturing is to ensure automated protection systems have predictable responses to malfunctions or failures.
The concept of functional safety applies to everyday life and every industry you can think of. The International Electrotechnical Commission (IEC) provides this example of transportation functional safety:
“When you board a train, the subway or a cable car, functional safety ensures that the doors close before the vehicle departs and that they don’t open while it is in movement. They also ensure that the railway signaling system helps avoid that an oncoming train crosses your train’s path.”
When systems fail to operate, significant disasters can occur. Safety standards, such as EN 50128, are designed to reduce risk tolerance around these events.
What is EN 50128?
EN 50128 is a certification standard issued by CENELEC (the European Committee for Electrotechnical Standardization). The international version of this standard is IEC 62279. This standard specifies the requirements for railway applications, including communication, signaling, and processing systems for railway control and protection systems software.
According to Engineering360, the European standard “specifies the process and technical requirements for the development of software for programmable electronic systems for use in railway control and protection applications.” It aims toward any practical use where there are safety implications. This European Standard applies exclusively to software, the interaction between software and its system, and all safety-related software used in railway control and protection systems, including:
Application programming
Operating systems
Support tools
Firmware
Why compliance with safety standards such as EN 50128 is critical to railway software and industrial manufacturing teams
Eliminating all chances of risk may not always be possible. However, manufacturers must continuously seek strategies to mitigate potential safety issues, which is why industry experts in industrial manufacturing have created standards, such as EN 50128, and IEC 62279, to reduce risk and support the development of safety-sensitive products.
According to TUV SUD, “functional safety ensures that safety risks due to hazards caused by the mal-functional behavior of systems are reduced to an acceptable level. These safety risks are increasing in the rail industry as rail technology is becoming more and more complex, with both hardware and software interacting in different ways and components that are sourced from multiple markets.”
How Jama Connect® Can Help Organizations Achieve EN 50128 Compliance
Compliance is an essential goal for organizations in regulated industries, but it is not the only factor when delivering safe and reliable products to market. Organizations need defined processes for development and production and detailed end-to-end traceability to achieve compliance, from high-level user needs to validation and verification.
Jama Connect® is TÜV SÜD certified for developing safety-related products. Jama Software® is the first vendor that is both SaaS and Agile to receive the certification. In 2019, Jama Software completed additional certification as a software tool for railway applications according to EN 50128.
Focus and rigor in the product development lifecycle drives compliance as an outcome. While the ultimate responsibility of functional safety remains with the customer, Jama Connect eases the path to compliance so companies can focus on building products right.
Ensuring Compliance & Managing Risk with Jama Connect
Jama Connect is engineered to ensure quality with frameworks aligned to key industry standards which streamline design, development, testing, and risk management while maintaining compliance. Teams can quickly see the full historical context around a requirement when they contribute to a project — reducing the probability of errors as well as the time and overhead spent on risk analysis.
https://www.jamasoftware.com/media/2022/08/2022-08-18-how-en050128-establishes-funtional-safety-standards-1.jpg5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-08-18 03:00:462023-01-12 16:46:26How EN 50128 Establishes Functional Safety Standards for Railway Software
Like many industries, the semiconductor industry has seen a dramatic change over the past several decades. Simple, single function devices have evolved into complex multi-function devices with firmware, supporting software and, in some cases, full reference designs. While the products that the semiconductor industry sells are still integrated circuits (ICs), in many cases the supporting software, documentation and system-level understanding are just as important as the product themselves. A key example of this are the products produced for the automotive industry that must meet the Functional Safety requirements of ISO 26262.
Early in the days of integrated circuit design, companies generally focused on developing single function products. The development focus was on continuously optimizing for different applications and in many cases improving performance metrics like power, speed, and bandwidth. Later came an increased focus on reducing product size and cost. The common thinking was that if team could build a product with better performance metrics than the previous generation, there would be a market for the product. For these teams the skill of circuit design and the capabilities of manufacturing were the ultimate competitive advantage. A great deal of system-level understanding is not required, although many teams had Applications Engineers with an understanding of the various applications their products would be used for.
For many companies in the semiconductor industry, circuit design and manufacturing are still competitive advantages. For others, an increased focus on integration has encouraged them to think in terms of providing a complete solution, rather than just products. Increasing levels of integration is often driven by a goal to decrease size and cost of the solution but doing so requires a better understanding of the end application and more systems-level thinking in developing the solution. This understanding of the end application leads to a focus on clearly understanding and communicating the requirements to ensure successful product development. While in single function products the requirements are often simple and the circuit design is the challenge, in more complex products the requirements can become quite complex and truly understanding the need is just as critical as executing on developing a solution.
No aspect of integrated circuit development increased functional complexity as much as adding firmware and software to the overall solution being provided. While adding software and firmware to a solution is often done to solve a specific problem, it quickly opens up such a wide range of functional possibilities that the complexity grows rapidly. While there are still teams focused on advancing the state of the art of circuit design, just as many (maybe more) teams are developing full solutions with a semiconductor element as well as firmware, software and even system integration. The ultimate representation of this trend is semiconductor companies providing complete reference designs that contain nearly all the engineering required to produce an end-product.
In the automotive industry, the trend of providing a complete system-level solution has not been as strong as in other industries like IoT or consumer, but another trend has emerged: providing a safe solution. Integrated circuits sold into automotive applications have long had to achieve some of the toughest reliability standards. Now it is increasingly common for vehicle electronics to impact the safety of the vehicle, so not just reliability is required, but also functional safety. Achieving functional safety requires a lot more than circuit design and process technology. It requires understanding of how failures in an integrated circuit can impact the system. It requires robust development processes not traditionally employed in the semiconductor industry.
Nowhere was the need for this more strongly articulated than at the “Guidance & Application of ISO 26262 to Semiconductors” conference held virtually in August 2021. In the first session of the conference, several automotive OEMs joined forces to explain how important it is for semiconductor suppliers to develop pre-integrated, pre-certified and pre-tested solutions that meet the requirements of ISO 26262 and place the minimum burden on system integrators to integrate the solution into their system and safety case. Functional Safety adds a lot of overhead to vehicle development and receiving complete solutions from their suppliers goes a long way toward reducing that burden.
While many semiconductor suppliers have been playing catch up to meet the requirements of ISO 26262, others are turning it into a competitive advantage. These suppliers are winning business on the strength of their functional safety competency. They have developed robust processes featuring robust requirements management, configuration management and safety analysis. As a result, they can provide their customers complete safety cases that save their customers significant time when integrating their solutions. Some are even furthering the state of the art in functional safety by participating in standards development. It is common for multiple suppliers to have technically equivalent products, so in these cases safety competence can become the deciding factor in which semiconductor solution an OEM or Tier 1 supplier ultimately selects.
With the automotive industry working toward fully autonomous vehicles, the importance of developing safe products is more critical than ever. It will take the whole industry working together to furthering the state of the art in all areas to achieve the goal of full autonomy. That state of the art includes both skillful circuit design and robust process that ensure safety.
Never has there been a time where it was more critical for the semiconductor industry to adopt new skills. Circuit design and manufacturing will always be the core competency of semiconductor companies, but for those focused on the automotive industry safety, it is increasingly necessary for safety to be a core competency. Developing this as a core competency can lead to increased market share in today’s exciting automotive market.
https://www.jamasoftware.com/media/2021/09/2021-10-6-safety-as-competive-advantage_1024x512.jpg5121024Adrian Rolufs/media/jama-logo-primary.svgAdrian Rolufs2021-10-06 03:00:102023-01-12 16:48:02Safety as a Competitive Advantage
This post on functional safety for autonomous driving is Part III in our three-part series with automotive expert Patrick Freytag. If you haven’t already, please go back and read Part I, which talks about how the automotive sector is changing – and Part II, which discusses ways to address functional safety.
Since functional safety has a product lifecycle approach, it has a wide impact on all processes in a company. As a newcomer to functional safety, it’s challenging to focus on the most important aspects, especially for new entrants in the knowledge-intensive automotive sector. Here are best practices based on my observations and experience.
Functional Safety for Autonomous Driving – Best Practices for New Market Entrants
Executive Management Team: Pay Attention to Functional Safety
Product safety should be at topic of conversation for the Executive Management Team (EMT) because of the legal responsibilities placed upon the company by deploying a vehicle to customers. The EMT should understand that it needs dedicated resources to achieve product safety. One of the most important tasks of the EMT is to implement a Safety Engineering Management and to assure that roles and responsibilities for quality and safety are defined and communicated in the company. Members of the safety team need a specific skill set, so it is important to invest in functional safety education and qualification. It is important to foster a quality and safety culture in the company. For that reason, quality and safety should be part of goal agreement and performance evaluation. Quality and safety have to be recognized as a core responsibility and a performance indicator for employees.
Project Management: Plan and Track Functional Safety
Project management has to incorporate functional safety in the product concept and development plan. The Project Manager (PM) should consider the additional time and cost in the project plan and the project budget. Product development plans must include quality and safety milestones and the related work products. What should be done if the PM doesn’t receive proof that quality and safety milestones are reached at the gate reviews, for example? Well, that’s for sure a red flag. Situations like these may point to deeper rooted issues, and should not be brushed under the rug. The PM should start a GAP analysis and request an action plan. I recommend escalating the issue to the executive team ASAP in case there is missing proof of product safety. It won’t get better without commitment and planned actions, the longer you wait the worse the situation will get. Since safety considerations most typically permeate several layers of system design, it is not an attribute that can be tagged on shortly before the start of production, it has to be implemented from the beginning.
Development & Functional Safety Team: Implement and Validate Functional Safety
Industry experience shows that functional safety is not a topic you can assign to one responsible person. For example, a technical safety concept is created by a team of software, hardware, and system-level experts and moderated by a systems architect in collaboration with functional safety engineers. This means that the functional safety manager is a role that is played a few times in a company, while the role of a safety engineer can be assigned to even an entire team. As mentioned, functional safety requires specific domain knowledge and safety engineering expertise. But what can be done if this expertise is missing in-house? My recommendation is to compensate it with external resources as an interim solution. Start functional safety education and qualification as a long-term solution. Safety must be addressed in product development with adequate engineering methods and domain knowledge to define safety requirements. These safety requirements have to be implemented, tracked, managed, verified, and validated to make sure that risk reduction is realized, and the product is safe.
The Evolution of Functional Safety for Autonomous Driving
The functional safety focus is on avoiding and mitigating failures in E/E systems. That also works well for Advanced Driver Assistance Systems (ADAS). When a failure is detected, the driver gets alerted, and mitigation measures are performed to reach a safe state. These systems are called fail-safe. Let’s take Adaptive Cruise Control (ACC) as an example. When a failure is detected, a warning will be displayed in the Instrument Cluster. This visual warning is typically combined with an acoustical warning to get the attention of the driver. The ACC function will be switched off, and the driver is in charge to control the vehicle’s speed and keep a safe distance again.
Additional Safety Considerations for Autonomous Driving
The ADAS safety mechanism described above will not be sufficient for a fully autonomous vehicle. It’s not possible to switch off the automated driving system because there is no driver in the loop to take over. An Autonomous Vehicle (AV) has to work under all (failure) conditions, it has to be fail-operational. An AV without a driver in the loop also needs situational awareness, understand the surrounding world, decide, and act. This situational awareness is created by data fusion from a variety of complex sensor systems based on lidars, cameras, and radars. The combined data is then interpreted to plan and take action. This interpretation and planning are achieved by complex algorithms, driven by Artificial Intelligence (AI) and Machine Learning (ML).
Today, many connected and ADAS-equipped cars are already available. Connectivity features and information sharing are increasingly used for updating vehicle features, maintenance-related diagnostics, and traffic services. This development will also increase the attractiveness of an attack on vehicles by hackers with different motivations and it introduces additional risks for vehicle cybersecurity.
Safety Concerns Due to System Limitations and Misuse
What happens if an automated driving system has no system failure but doesn’t work as intended? Unsafe behavior could be triggered by limitations in the sensor systems, extreme conditions, or unforeseen situations. In addition, misuse could confuse the AI algorithms and result in unsafe behavior too.
An example of misuse of an ADAS was showed by Consumer Reports. Consumer Reports reported in April 2021 that it was able to trick a Tesla into driving in autopilot mode with no one at the wheel. Real-life proof followed in May – Police arrested Tesla driver for operating his car from the back seat while traveling on a San Francisco Bay Area freeway. The officer confirmed the sole occupant was in the backseat, so he took action to stop the car and saw the occupant move to the driver’s seat before the car stopped. In response, Tesla activated the cabin camera with a software update to detect and alert driver inattentiveness while autopilot is engaged for Model 3 and Model Y end of May.
Here a typical example of limitations, an AV is driving and confronted with black ice conditions. While an experienced driver should be able to comprehend the situation and respond properly, an AI-based AV might not. Without sensing the icy road condition, an AV might drive faster than is safe for the condition.
As a result, there has to be an addition to functional safety considering safety violations that occur in absence of a system failure.
Safety of Intended Functionality or SOTIF (ISO/PAS 21448)
The publicly available specification ISO/PAS 21448, titled “Road vehicles — Safety of the intended functionality” was published in 2019. SOTIF is defined in the standard as: “The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons.” The goal of SOTIF is to avoid situations where vehicles are working as designed, but are failing under real-world scenarios. ISO 21448 provides guidance on the design, verification, and validation measures to achieve the SOTIF. The current version covers Advanced Driver Assistance Systems (SAE J3016 L1 and L2). It can be considered for higher levels of automation; however, additional measures will be necessary.
The Standard for the Evaluation of Autonomous Products (ANSI/UL 4600)
The UL 4600 standard was issued in April 2020 with the scope of the Safety Evaluation of fully Autonomous Driving Systems that operate without human intervention. The goal of UL 4600 is to ensure that a comprehensive safety case is created, including safety goals, argumentation, and evidence. UL 4600 covers the safety principles, risk mitigation, tools, techniques, and life-cycle processes for building and evaluating a safety argument for vehicles that can operate in an autonomous mode without human supervision. Therefore, the ML-based system aspects of the autonomous operation are covered. UL 4600 works well with existing automotive safety standards such as ISO 26262 and ISO/PAS 21448 by building on their strengths while also filling their autonomy-specific gaps.
Conclusion
The safety challenge for autonomous vehicles can’t be addressed with a single standard as of today. As we move on from existing Advanced Driver Assistance (L1 and L2+) to fully Automated Driving Systems (L5) the standards and methods will evolve too.
Current state-of-the-art automotive safety is achieved with a combination of different engineering methods and processes:
Functional Safety (ISO 26262)
Guards the E/E malfunction behavior due to systematic and random hardware failures for vehicles with a human driver present responsible for safe operation
Safety of the Intended Functionality (ISO/PAS 21448)
Deals with the functional limitation regarding the absence of unreasonable risk due to hazards resulting from functional insufficiency of the intended functionality or reasonably foreseeable misuse by persons. SOTIF covers L1 & L2 ADAS vehicles with a human driver present responsible for safe operation.
Cybersecurity engineering (ISO/SAE 21434)
Protects road vehicle systems and components from harmful attacks, unauthorized access, damage, or anything else that could interfere and compromise safety functions
Evaluation of Autonomous Products (ANSI/UL4600)
Proofs the safety of fully autonomous road vehicles that can operate without human supervision
Take Away:The combination of different engineering methods is needed on the way to fully Autonomous Driving
Functional Safety helps you to do things right
Safety of Intended Functionality helps you to do the right things
Cybersecurity helps to protect the safety functions from being compromised
Evaluation of Autonomous Products helps you to provide proof that you did enough safety engineering work to achieve a safe autonomous product
This blog post concludes the 3-blog miniseries on automotive insights and best practices on the way to autonomous driving. Special thanks to Jama Software for the opportunity to share my observations and experience with you. I hope you enjoyed reading my thoughts and got useful insights into the complex and interesting world of automotive safety and autonomous driving.
https://www.jamasoftware.com/media/2021/06/2021-06-08_implementing-fuctional-safety-part-3-Freytag_1024x512.jpg5121024Patrick Freytag/media/jama-logo-primary.svgPatrick Freytag2021-06-08 03:00:182023-01-12 16:49:06Automotive Engineering and Management Methods for Modern Vehicle Development – Implementing Functional Safety for Autonomous Driving
My last blog post covered why and how the automotive sector is changing fast over the last few years – you can find that post here. A common expectation is that our future cars will be connected, automated, shared, and electric. In a current Motional Consumer Mobility report, Americans were asked what is their most important consideration to use a self-driving vehicle. Nearly two-thirds of Americans (65 percent) say safety is the most important consideration when deciding to use a self-driving vehicle. So let’s take a closer look at automotive functional safety and how to deliver a safe product.
Safety Considerations for Product Design
Modern cars are a complex piece of technology. They are connected, have sophisticated Infotainment Systems (IVI) and Advanced Driver Assistance Systems (ADAS). You will be surprised about the amount of software used in the 30 to 70 electronic control units in a car. There are up to 100 million lines of code deployed in a modern high-end car today. System complexity will increase even more when we move beyond ADAS-supported driving to Automated Driving Systems (ADSs) in the future.
The challenge for the industry is that new potential hazards may arise with the increasing use of electronics and software in cars. Apart from complex technology and consumers’ expectations, we will get regulations covering the safety of future cars. In the U.S., this is the responsibility of the National Highway Traffic Safety Administration (NHTSA).
Defined by the Vehicle Safety Act in 1966, the NHTSA has the sole authority to make final decisions on rules and safety standards for future road vehicles. Once the NHTSA establishes a standard, the Agency is required to ensure that manufacturers comply when producing new vehicles.
In 2016 the NHTSA published “Vision for Safety,” a non-regulatory approach to automated vehicle technology safety. “Entities are encouraged to follow a robust design and validation process based on a systems-engineering approach to design ADSs free of unreasonable safety risks. The overall process should adopt and follow industry standards, such as the functional safety process standard for road vehicles…”
Which industry standard is the NHTSA referring to?
The mentioned standard is the ISO 26262 standard. First issued by International Organization for Standardization (ISO) in 2011 and later updated in 2018. The ISO 26262 is titled “Road vehicles – functional safety,” the first comprehensive voluntary industry standard for safety engineering of Electrical and Electronic Systems (E/E) in road vehicles. This standard recognizes that safety is a system attribute and can be addressed using systems engineering methods. ISO 26262 emphasizes the importance of implementing a safety engineering management and fostering a safety culture.
What is functional safety and how to comply?
Functional safety is defined as the “absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems.” The goal of ISO 26262 is to ensure safety from the earliest concept to the point when the vehicle is retired. To ensure vehicle safety, the standard outlines an automotive safety life cycle that describes the entire production life cycle.
Specific steps are required in each phase of the safety life cycle. One of the most important steps at the beginning of the safety life cycle is the Hazard & Risk Analysis of potential hazards (HARA). The result is an Automotive Safety Integrity Level (ASIL) classification of the hazard and the formulation of an overall safety goal. Safety goals are basically the level of safety required by a system or component to function without posing any threats to the vehicle.
An ASIL is assigned by evaluating three risk parameters, severity, exposure, and controllability. Severity defines the consequences to the life of people due to the failure that may occur.Exposure is the likelihood of the conditions under which a particular failure would result in a safety hazard.Controllability determines the extent to which the driver will be able to control the vehicle should a safety goal be breached due to the failure or malfunctioning. An ISO 26262 method provides guidance on how to assign the ASIL for a hazard once severity, exposure, and controllability are determined.
In the next step, a functional safety concept is developed for each safety goal. The functional safety concept defines functional safety requirements within the context of the vehicle architecture, including fault detection and failure mitigation mechanisms, to satisfy the safety goals. Then the technical safety concept is developed to specify the technical safety requirements within the system architecture. The technical safety concept is the basis for deriving the hardware and software safety requirements that are used for developing the product. These safety requirements have to be traced, managed and validated through product development to assure the delivery of a safe product.
Functional Safety describes a risk-based system engineering approach to avoid unreasonable risk. From a business aspect, using ISO 26262 as a guideline helps you to avoid costly product recalls due to safety hazards. Tesla recalled roughly 135,000 Model S and Model X vehicles over Touch-Screen failures in February 2021. The move came after the National Highway Traffic Safety Administration requested a safety recall. NHTSA asked for the recall because the center display in some models can fail when a memory chip runs out of storage capacity, affecting safety functions such as windshield defogging and defrosting controls, exterior turn signal lighting, and rearview backup camera display.
Following the standard minimizes the risk of harm to people and non-acceptance of your products by the market. In particular, automobile manufacturers have a legal responsibility to design their vehicles to guarantee driver, passenger, and pedestrian safety. As a consequence, automobile manufacturers can be named as defendants in a product liability suit. For example, Toyota Motors agreed to pay $1.2 billion to settle the Justice Department’s criminal investigation into whether the company hid safety defects related to unintended acceleration in 2014.
Takeaway
Functional safety is an essential part of product development and needs to be addressed early in the concept phase and considered through the full product life-cycle. ISO 26262 offers an engineering guideline and methods to avoid or at least mitigate systematic failures and random hardware failures of Electrical and Electronic Systems. The derived functional safety requirements have to be implemented at the lowest level up to the system level, both from a hardware and software perspective. This offers the ability to prove that the added E/E-systems are free of unreasonable safety risks.
The pragmatic engineering approach is to use existing knowledge, or how I call it, to use the industry’s memory. You should look at the ISO 26262 series as the framework, and set of guidelines and methods. ISO 26262 can help you with system engineering methods for a safe product and still give you some flexibility in the development process. This is especially helpful for newcomers to the automotive industry, who may lack specific automotive safety engineering experience.
Let’s put it that way, using existing engineering methods and knowledge is like standing on the shoulders of a giant – you can see further. This is even more true for automotive product safety because there is no room for trial and error.
Stay tuned: The next blog post in this series will give real-life advice on how to implement functional safety in your organization and products, and a glance at the evolution of functional safety for autonomous driving.
https://www.jamasoftware.com/media/2021/04/2021-05-04_automotive-engineering-freytag-part-2_1024x512.jpg5121024Patrick Freytag/media/jama-logo-primary.svgPatrick Freytag2021-05-04 03:00:192023-01-12 16:49:12Automotive Engineering and Management Methods for Modern Vehicle Development – Addressing Functional Safety
Editors Note: This post on safety and security in in automotive development is a guest post by from our partner Ansys. To learn more about Ansys, visit their website.
Safety and security have always represented a driving force in automotive engineering. Today, these performance criteria are more important than ever, as vehicles continue to grow exponentially in technological complexity.Advanced technologies deliver benefits, but also create new risks and potential failure modes.
With sales of electric vehicles projected to reach $567 billion by 20251, the design of powertrains and battery management systems has been brought to the forefront. Automakers also hope to capture a share of the global autonomous vehicle market, which will account for $556.67 billion by 20262, placing more focus on embedded control software, perception systems and sensors.
Before these diverse innovations can be commercialized, they must be analyzed and verified for reliable performance under every operating condition. Equally important, all electronics must be proven to work together at the system level, which means developing a robust system-level architecture, testing every integration point, and identifying and addressing weaknesses.
The Industry’s Leading Software for Automotive Modeling, Analysis and Simulation
Mastering these diverse, complex automotive engineering tasks may seem overwhelming ― or even impossible ― but there is good news. Anestablished leader in engineering simulation for over 50 years, Ansysenables automakers to navigate the complex design and verification challenges associated with electrification, ADASand other technology advancements.
The depth and breadth of the Ansys portfolio mirrors the complexity of today’s vehicle designs ― bringing modeling, analysis and simulation together in a robust, connected platform. From physics-based simulations that focus on crash-worthiness to the verification of embedded software, sensors, cameras and radars, Ansys solutions help automakers analyze every component in today’s cars.
Navigating the UniqueChallenges of Safety and Security
Regarding electronics safety and security, software from Ansys helps automotive engineers by supporting safe software development, functional safety analysis and cybersecurity analysis.
Safer Embedded Software Development
Underlying the advanced electronic systems found in modern cars are millions of lines of embedded software code that ensure their flawless operation under every drivingscenario. Ensuring that the overall software model, and every line of code, deliver the desired functionality is critical to protecting the safety of human passengers. To meet the highest safety standards and comply with regulatory guidelines, software engineers must subject this code to rigorous testing.
With Ansys SCADE, engineers can streamline design and verification processes via automatic code generation of ISO 26262 critical software up to ASIL D. SCADE can be easily integrated into existing AUTOSAR development flows for software components, eliminating time-consuming manual reviews.
For example, as Subaru created control software code for its first hybrid vehicle, it automated 95% of the development process by relying on Ansys SCADE to generate code for the car’s innovative engine, called the e-BOXER. Today, it only takes Subaru engineers half a day to implement a model for the e-BOXER’s electronic control unit (ECU) once the control logic has been defined. This enables Subaru’s developers to modify the ECU’s logic and architecture much more frequently and easily as they explore continuing design innovations.
Functional safety analysis ensures that automotive electronics deliver reliable performance over time, without system failures leading to unreasonable risk.This analysis must encompass the entire electronics architecture, including down to the chip level.
Ansys medini analyze streamlines and automates functional safety analysisvia a model-based environment that supports executingthe safety-related activities required by applicable standards like ISO 26262. It has helped many customers reduce time and costs, without sacrificing analytic rigor.
For example, LiTHIUM BALANCE develops battery management system (BMS) solutions for electric vehicles in keeping with the most stringent safety, performance and reliability standards. By leveraging medini analyze, engineers at LiTHIUM BALANCE quickly and affordably manage the functional safety verification of their BMS designs.
By providing an easy-to-understand, visual representation of complex electronics and their integration points, Ansys has benefited ZF Friedrichshafen AG, a global technology company that supplies systemsto automakers. Ansys medini analyze has streamlined and accelerated functional safety analysis for hardware, software and systems ― delivering possible efficiencies including an up to 50% reduction in the time devoted to these tasks.
The emergence of automated driving has brought an even greater challenge: What if componentssuch as sensors are working as designed, but their capabilities fall short under real-world conditions?A new standard, ISO 21448, focuses on safety of the intended functionality (SOTIF). Ansys medini analyze helps engineers not only identify weaknesses, triggering conditions and causaleffects, but alsointerfaces with simulation and testing tools to validateperception software and other ADAS components.
The increased amount of software and connectivity in cars has made them vulnerable to cyberattacks. Recent headlines, as well as the ISO 21434 cybersecurity standard, have made cybersecurity analysis an essential part of the automotive development process.
Ansys medini analyze for Cybersecurity addressessystem-level security viaan easy-to-use modeling and analysis environment, ensuring that the complex electronics architectureis impervious to attacks. By quickly identifying and addressing potential threats and vulnerabilities, engineers can deliver secure products, reduce time to market, maximize profits and comply with upcoming cybersecurity regulations.
Today many automotive leaders are applying Ansys solutions, while also leveraging Jama Connect for product development. A value-added partnership between these companies means that Jama customers canseamlessly and directly integrate Ansys SCADE and Ansys medini analyze. For the first time, the automotive electronics development and testing process is supported by a linked set of industry-leading software tools.
To learn more about how Jama Connect for Automotive can help your team achieve safety and security compliance, streamline development, and speed time to market, download our solution overview.
https://www.jamasoftware.com/media/2020/10/2020-10-28_EnsuringSaftetySecurity_ANSYS_1024x512.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2020-10-28 03:00:332023-01-12 16:50:12Ensuring Safety and Security for Automotive Development
Designing complex electronic systems not only requires a significant number of specialized stakeholders, but also efficient collaboration during safety-critical product development and verification activities. With some teams working remote and working together around the globe, there may be gaps in communication, locations, or tools that need to be overcome in order to deliver the expected product on time and on budget. In a recent webinar Michael Jastram, Senior Solutions Architect at Jama Software and Francois Xavier Dormoy, Senior Product Manager at Ansys discuss how you can bridge these gaps by integrating a product development platform, such as Jama Connect, together with a model-based embedded software tool, such as Ansys SCADE. From high-level requirements to verification and validation (V&V) activities to implementation, this allows you to share a single source of truth among the stakeholders and facilitate alignment across teams.
Below you’ll find an abbreviated transcript and the full webinar recording.
Bridging the Gaps in Safety-Critical Product Development
Michael Jastrom: In case you’ve never heard of Jama Software, Jama Connect is a solution for product development. Product development includes, of course, capturing the requirements, requirements management but also activities like test and quality management, which gives you end to end traceability. Also, risk and hazard analysis because a lot of our customers are using Jama Connect for functional safety-critical work the same way that
Ansys SCADE is being used. Jama Connect is a platform that achieves these things by providing you with key capabilities, like traceability, collaboration, reuse, and many others. I don’t want to go here into detail. In a minute, Francois and I will give you a live demonstration so that you can actually see how all this plays out in practice.
One thing that is very important that I would like to point out is that Jama Connect is an open platform. It is very easy to seamlessly integrate it with other tools. We see Jama Connect as the best of class solution. For this part of your development you want to use best of class and so do you want for others. That’s why you’re using SCADE, I assume. We ensure that you have a seamless integration.
Before I give you a tour of the solution, let’s look at the problem with respect to product development today. In product development, you typically follow the V-model if you have to do with functional safety critical systems. This has been practiced since the ’60s very successfully. There’s just one problem with it. The V-model in systems engineering tends to be slow. By the time you define your concept of operations, you went all the way down to implementation there. By the time you can do the verification and validation activities of the top level, a lot of time passed. There’s a lot of interest these days in HM methodologies. One question that we often hear is how do you apply HM methods in the context of functional safety critical work and systems engineering. The answer to that we call continuous engineering.
This is how it works and where Jama Connect applies. Jama Connect basically covers the top two thirds of the V-model by providing you with a platform for modern requirements management that gives you cross functional collaboration, which allows you to easily exchange information, capture decision, conduct reviews of electronic signatures, and so forth.
At some point, you reach the point where the scope of Jama Connect ends. That’s where something like Ansys SCADE comes in. We provide you with real time and seamless traceability across two boundaries so that you have end to end traceability with best of class solutions. On the top right here, this is again where Jama Connect comes in. Jama Connect also supports you with test management activities so that you have end to end traceability from your requirements all the way to your test cases and test results. Jama Connect doesn’t end there because Jama Connect provides you with reuse capabilities that allows you to build the next version by using branching and merging of variant management so that you can easily manage multiple variants and take advantage of the good work that you already did.
The next question is how do you actually apply that in practice? This requires a paradigm shift. This is visualized on the left-hand side here by depicting the traditional systems engineering approach, which tends to be document based, which you can see here with example outlines from the corresponding RS standard. Now, we haven’t worked with documents in systems engineering for a while. There are tools around for requirements management. Yet, if you look at all the generation of requirements tools, that still has a very strong document feel to it. In Jama Connect we really switch away from that and go to an item-based mindset where you have fine grade traceability. Obviously, to really understand on a fine grade level what the impact of change is, where you have gaps in your coverage, and so forth.
Here you see you simply find relationship model that shows you how you can connect to various items. For example, you can have themes and epics, which are terms from the ancient world, but still mixed it up with things like product concept and system architecture, which are more traditional systems engineering. If we have a look at that, then you get something like this. This relationship diagram has been actually taken directly from Jama Connect so you can flexibly adapt it there. The arrows indicate the traceability capabilities. For example, you that epics and user stories are connected. Jama Connect will tell you if you have a gap between your epic and your user story. You can find gaps in your coverage. Jama Connect helps you with impact and change management. If you change the epic, then all the connected user stories and validation test cases will be marked as suspect. There are a number of other features, roles, workflows, templates. A number of capabilities that really allow you to have repeat iterations following the traditional systems engineering process but with an agile mindset. We have customers from many different industries. Just to provide you with one example, one of our customers from the avionics industry used Jama Connect in a lot of areas. Just to pick up one metric, they managed to increase the speed of resolving issues by 30% by using what Jama Connect provides you with.
Francois Xavier Dormoy: Yes, the topic is how we can make this synchronization and how we can integrate both SCADE models, and these requirements, and these traceability. In fact, we have in SCADE and in all SCADE tools, we have a gateway. A gateway to requirement management tool, like Jama Connect. For instance, in Jama Connect, of course, you will be able to create requirements, to manage requirements, manage traceability links. You can create links. You can see all the traceability. You can perform your impact analysis. You can generate matrices, etc. All these, of course, will be done in Jama Connect and you will use SCADE for design, for the architecture, for the testing, etc.
What we allow in this gateway is for people designing to have a look at the requirements. We have a way to import in SCADE requirements and we have a way in SCADE to create links between SCADE elements, SCADE artifacts, and any requirements. These links will not be stored in SCADE. They will be stored in Jama Connect. We have the six portraiture in order to export back to Jama SCADE artifacts together with traceability.
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.
https://www.jamasoftware.com/media/2020/10/2020-09-29_ansys-webinar_recap.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2020-10-20 03:00:202023-01-12 16:50:14[Webinar Recap] Bridging the Gaps in Safety-Critical Product Development
My last blog post covered why and how the automotive sector is changing fast over the last few years – 
