Functional safety (FuSa) is a big deal, especially when driving a car. My beloved 1998 Acura RL recently exhibited a strange behavior at 239K miles, after making a turn the steering wheel would stay tilted in the direction of the last turn instead of straightening out. The auto mechanic pinpointed the failure to the ball joints, so I ended up selling the vehicle to someone who was willing to make the repairs. Today our cars are filled with complex electronics, semiconductor IP, firmware, software, sensors, actuators and a variety of propulsion systems: internal combustion engines, hybrids, and electric motors. How should we meet functional safety requirements for industries like automotive, medical and life-critical domains?
Complying with functional safety requirements is an emerging field, and in the automotive industry we see the quest for Advanced Driver Assistance Systems (ADAS) inch towards autonomous vehicles. A recent White Paper written by Vadim Iofis of Methodics brought me up to speed on the challenges, and their approach of using an IP-centric flow to reach compliance by tracing down to the hardware and software component levels.
If each component in a system is designed and developed with certified tools and processes, then it becomes functional safety compliant. Here are examples of tools that are certified for FuSa compliance:
- Rational DOORS – requirements and specification tools
- IBM RSAD – software design and UML modeling
- Cadence Verification Suite – IC design verification
- Software IDEs
Your functional safety team ensures that each new version of a tool is certified before it’s used in a FuSa-compliant design and development process. Even the design and development process becomes FuSa compliant, adopting rules for approved tools and listing out the steps on verifying components, so that requirements and specifications are met. Both tools and process are version controlled. Wokflows are described using the Business Process Model and Notation (BPMN) 2.0 standard.
Even when your team has defined FuSa-compliant tools, processes and workflows, there’s still the issue of tracing the certifications down to each hardware block and software component. Where does this traceability come from?
Methodics has an approach to this traceability concern, and that is by defining each project as an IP hierarchy, where IP can be either a hardware design block or a software component. The Methodics Percipient tool provides IP management, versioning IP, and linking an IP object to hardware or software. Each IP also has metadata to enable traceability of certificates, process documentation and workflows.
Project Example
OK, time to get specific and look at a typical ADAS application for an Automatic Collision Avoidance System (ACAS), breaking up the project into hardware and software components as shown below.
Shown in Yellow are Containers, a way to use hierarchy with groupings of other IP blocks. The Green blocks represent hardware blocks, Blue blocks are for software components, and finally the Purple blocks are the FuSa artifacts for each component to certify that the design and development process are meeting your team’s compliance standards.
The Sensor Package on the left-hand side has sensors, hardware and FuSa artifacts (tool certifications, Design Workflow Model using BPMN 2.0 diagram). The ACA Module on the right-hand side is all software components and FuSa artifacts, and you could use Git or Perforce as a code repository.
Using the Percipient tool it only takes a few steps to create the Sensor Package hierarchy.
You can define using hierarchy for both hardware blocks and artifacts. Each artifact has certification IPs attached, and in this case it was from Word documents. Your team can update each new certification version, add new project components and certify each component.
Summary
It’s much easier to reach FuSa compliance in a system design by using an automated approach for hierarchy and traceability like that found in the Percipient tool from Methodics. Both hardware and software components are linked with their FuSa artifacts as proof of compliance. The functional safety manager on your team can now inspect the version history and know which releases belong to which tool certification, even see when and where anything was changed.
Why use manual, error-prone methods when a vendor like Methodics has helped automate so much of the FuSa process. Request the full 11 page White Paper here.
Related Blogs
- IP Lifecycle Management and Permissions
- Webinar: ISO 26262 Compliance
- A Brief History of Methodics
- A Brief History of IP Management
Next Generation of Systems Design at Siemens