example of practice content practice content is organized into sections: enterprise systems...
TRANSCRIPT
Example of practice content
• Practice content is organized into sections: • Enterprise• Systems development• Software development
• Delivery processes detail workflows
Views from different perspectivesContent is navigable:
Workflows/
Process
Task Descriptions
Work productsRoles
Managing the process
• Practice content is used to drive process governance and task automation in RTC• Processes provide the basis for work item templates
• Implemented as tasks in RTC
• Work item templates help you create a number of tasks and allocate them to teams:
• Standardize the process
• Facilitate project governance
Accessing Practice content• Tasks in RTC are linked back to practice content
Applying the practices to specific industries• Each of the practices for the
different industries (automotive, medical, and aerospace) is written in the language of the industry.
• Consists of:• Practice content:- Published
website• Process template:- The means
of customizing Rational Team Concert
• Some practices have extra content:
• DOORS templates• Compliance certificates• Rhapsody profiles
• ISO-26262 (Automotive)• DO-178 B/C (Aerospace)• IEC-62304 (Medical)
What is ISO 26262 ?
• ISO 26262 (derived from principles in IEC 61508)
• Functional Safety for EE Systems in passenger vehicles (<3.5 tonnes), i.e. Automotive as opposed to Trucks and Buses
– anti-lock brakes, air bags, traction control, electronic cruise control, adaptive cruise control, collision avoidance, lane change control
– front windshield defroster/defogger, rear windshield (backlite) defroster, auto-on headlamps, auto-on running lights, seat-belt pre-tensioners, low tire pressure warning system, engine, electric-assist power steering.
• Covers the management and technical aspects of the complete safety development lifecycle
• Takes a risk-based approach for determining risk classes (Automotive Safety Integrity Levels, ASILs).
• Definition of optional, recommended and highly recommended methods for development activities within system-, hardware and software development depending on defined ASIL
• Design safety into the system from the outset
• ISO 26262 covers the complete development lifecycle from Lust to Dust
Available practices and tools for ISO 26262
1 Vocabulary
2 Management of functional safety
10 Guideline on ISO 26262 (informative)
9 ASIL-oriented and safety-oriented analysis
8 Supporting processes
3 Concept phase
4 Product development
on system level
5 Hardware development
6 Software development
7 Production and operation
ISO 26262
DOORS/
Rhapsody
Rhapsody
Test/ Condctor
RQM
Requirements management (DOORS)
Configuration Management (RTC)
Change management (RTC)
DOORS
Rhapsody
RQM (test definition)
DOORS
RQM
(test results)
IoT
Big Data
Analytics
Overview of Concept Phase
• Understanding what the item is intended to do at the functional level
• Requirements collection and understanding
• Determining if the safety lifecycle needs to be tailored or not
• New or modified functionality or reuse of existing systems that has already been qualified
• Hazard analysis and risk assessment leads to • Determination of ASILs, • Safety goals• Safety requirements
• Develop strategies to reduce hazards and risks
• Redundant communication systems• Dual functionality• Use of watchdogs• Majority voting systems
• Normally about reducing single point failures so that the probability of two failures in the system occurring simultaneously is very low
3.5 Item definition requirements and models
• Requirements captured in a Requirements management tool (i.e. DOORS) as System requirements
• Import requirements into the modelling tool
3.5 Item definition requirements and models• Create an Item
Definition Model (typically based on a Feature)
• Dependant upon UC prioritisation so created in an Agile manner
• Need to capture, Functional Architecture, Interfaces and Behavior
• State and Sequence diagram
• Make it executable to help understand the behavior
• Trace model elements to initial system requirements
3.7 Hazard Analysis and Risk Assessment
• Employ Safety Analysis profile • Lightweight profile to enable
FTA and FMEA• Adapted for Automotive
• From Fault Tree analysis you derive the potential causes of the hazardous event
• Apply hazard analysis to these faults and identify ASILs
IBM Software Group | Rational software
© 2011 IBM Corporation 12
Requirements management for ISO 26262• Do not use Excel or Word• Use a proper RM tool• Customers want to Capture Severity,
Probability and Controllability attributes
• Determines ASIL
• Consistent requirements module structure to capture relationships between
• Stakeholder (Item Definition) Requirements
• Functional Safety Requirements• Technical Safety Requirements• System Safety Requirements• HW and SW safety requirements
• Automatic propagation through Safety Requirement Hierarchy of ASIL
• DOORS and DNG qualified with TUV for use as an ISO 26262 tool