Example of practice content

• Practice content is organized into sections:

• Enterprise
• Systems development
• Software development
• Delivery processes detail workflows
 Views from different perspectives
Content is navigable:

Task Descriptions

Workflows/
Process

Roles Work products

 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

ISO 26262 1 Vocabulary

2 Management of functional safety

DOORS/ DOORS DOORS IoT

4 Product development
Rhapsody RQM
Rhapsody Big Data
RQM (test definition)on system level (test results)
Analytics
3 Concept Rhapsody 7 Production
phase Test/ Condctor and operation
5 Hardware 6Software
RQM
development development

Requirements management (DOORS)

Configuration Management (RTC)
8 Supporting processes
Change management (RTC)

9 ASIL-oriented and safety-oriented analysis

10 Guideline on ISO 26262 (informative)

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

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

© 2011 IBM Corporation 12