model based systems and software engineering an overview of the ibm rational solution

© 2013 IBM Corporation

Innovation for a smarter planet

Model Based Systems and Software Engineeringan overview of the IBM Rational solution

Edmund Mayer, Systems Solution Architect20 June 2013


Software and Systems Engineering | Rational

Abstract topics

� Capturing and enacting workflow descriptions with Method Composer

� Project planning and collaboration with Team Concert– Work management– Change and process management– Dashboard and metrics

� Systems and software development with DOORS and Rhapsody

� Document publishing with Publishing Engine

� Model based test with Rhapsody TestConductor

2 2



3

IBM Rational Solution for DO-178CProcess Definition and EnactmentModel Based Systems and Software EngineeringTesting

3



IBM Rational Solution for DO178B/C

� A set of practices, customizable process guidelines, and compatible products to help organizations develop products for certification under DO-178B/C

� Goal – to help provide evidence of the consistent development of safe software in a cost-effective, efficient, and productive manner

� The process may be applied to any appropriate development tooling but is specifically optimized for the Rational Systems and Software Solutionconsisting of tools

– Rational Team Concert

– Rational DOORS

– Rational Rhapsody

– Rational Quality Manager



Rational solution for Systems and Software Engineering

QUALITY MANAGEMENTAchieve “quality by design” with an

integrated, automated testing process

ARCHITECTURE & DESIGNUse modeling to validate requirements, architecture

and design throughout the development process

REQUIREMENTS MANAGEMENTManage all system requirements

with full traceability across the lifecycle

BEST PRACTICES AND SERVICE OFFERINGS

Open Services for Lifecycle Collaboration

COLLABORATION, PLANNING & CHANGE MANAGEMENTCollaborate across diverse engineering disciplines and development teams

5



The SSE solution uses both Jazz and OSLC tool integrations

OSLC tools:• DOORS 9.5• SA• Rhapsody• ….

Jazz tools:• RTC• RQM• DOORS NG• RDM • …..



7


7



IBM Rational Solutions for DO178-Cprocess adoption made easy

� Role-based guidance available as a web site

� Integrated Software Development Process for DO-178B/C (ISDP-178)



Characteristics of effective process management and use

� Authoring and capturing process descriptions

� Tailoring and configuring process content

� Process reuse

� Deploying and accessing process information (in context)

� Process enactment and workflow enforcement

9



Integrated process and tools

� Process enactment through a Rational Team Concert (RTC) “process template”

� Easy creation of work assignments consistent with the documented practice content

� Assignable to team members

� Visible in dashboards

� Alerts and feeds available



Rational Team Concert (RTC) Plan Definition



Rational Team Concert (RTC) Plan Definition

� Unified view of Information

– What - Work Items

– Who – Project Area / Team Area

– When – Iteration



13

Process support across the development organization

� Sample showing different development teams following different processes



14



Demonstration overview

� Create new DO-178C project– Process template – roles, plans, views, work items

� Review System-level project– Personal and mini dashboards– Update plan for changes

15 15



16



17


17



18

Manage requirements across lifecycle and across disciplines using Rational DOORS

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element• Traceability Reports: consistency with driving design elements• Impact Reports: other design elements affected• Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational

procedure• Traceability Reports: Procedure Attribute

1.1.2. Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements• Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure• Impact Reports: Procedure Attribute

1.1.5. Create forward impacts to design elements within and across any project milestone• Impact Reports: Milestone Attribute

1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements• Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements• Link Change Design Object with affected design element(s)• Traceability Links and Reports from affected design element(s)• Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority

information• Change Decision Objects with following Attributes:• Disposition Attribute• Decision Attribute• Rationale Attribute• Owner Attribute• Management Approval Attribute

1.2.2. Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute• Change Design Object Impacts Link on Procedure Attribute

1.2.3. Provide associations within and across any project milestone• Change Design Object Traceability Link on Milestone Attribute• Change Design Object Impacts Link on Milestone Attribute

1.2.4. Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements• Change Design Object Impacts Link to linked design elements

1.3. Mange the change process• Design Change Module• Design Change Reports• Object History• Object History Reports• Versions• Baselines

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element• Traceability Reports: consistency with driving design elements• Impact Reports: other design elements affected• Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational

procedure• Traceability Reports: Procedure Attribute

1.1.2. Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements• Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure• Impact Reports: Procedure Attribute

1.1.5. Create forward impacts to design elements within and across any project milestone• Impact Reports: Milestone Attribute

1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements• Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements• Link Change Design Object with affected design element(s)• Traceability Links and Reports from affected design element(s)• Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority

information• Change Decision Objects with following Attributes:• Disposition Attribute• Decision Attribute• Rationale Attribute• Owner Attribute• Management Approval Attribute

1.2.2. Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute• Change Design Object Impacts Link on Procedure Attribute

1.2.3. Provide associations within and across any project milestone• Change Design Object Traceability Link on Milestone Attribute• Change Design Object Impacts Link on Milestone Attribute

1.2.4. Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements• Change Design Object Impacts Link to linked design elements

1.3. Mange the change process• Design Change Module• Design Change Reports• Object History• Object History Reports• Versions• Baselines

User Requirements Test CasesDesign

Technical Requirements

End-to-end visual validation in one view

Traceability to/from work items

Traceability to/from tests

Requirements change management



19

� Capabilities� Specify, design and develop systems and

software for technical, embedded and real-time solutions, including those based on multi-core architectures

� Validate and verify designs with model based simulation and test throughout the product lifecycle

� Develop complete C, C++, Java and Ada applications, working in either the code or model while ensuring the two remain in sync

Model-Based Systems Engineering and Model-Driven Development for real-time, embedded systems using Rational Rhapsody

� Benefits

�Build the right product through optimized communication and collaboration

�Eliminate defects early and increase quality by continually testing the design

�Reduce development time by automatically generating applications and documentation



20

Rational Publishing Engine

� Automate the generation of documentation, from multiple sources



21



Demonstration overview

� Model based functional analysis– Using models to improve the quality of requirements

� Requirements driven software development– Using models to generate readable and certifiable code

22 22



23



24


24



�Define test cases with sequence diagrams, statecharts, flowcharts or even code� OMG UML Testing Profile

�Automate testing tasks� Create Test Architecture� Execute and monitor tests

�Host level and target based execution� White-Box, Black-Box for design validation� “Offline testing” mode - for testing on target � C++, C, Java, Ada Supported

�Definition and management of regression tests

�Reporting of results, coverage and traceability

Rhapsody TestConductor Add-on for Model-Based Testing

�Traceability across lifecycle – from requirements to integration



DO-178 qualification of software development and verification tools



Rhapsody Kit for ISO 26262, IEC 61508, and DO-178B/C

� Overview Document : describes the contents of the Rhapsody kit

� Rhapsody Reference workflow : provides an exemplary workflow for modelling, code generation and verification in safety critical

� Rhapsody TestConductor Add On Workflow : describes testing activities and objectives

� Rhapsody TestConductor Safety Manual : provides additional information for using TestConductor in safety related applications

� TÜV SÜD Certificate for Rhapsody TestConductor Add On

� TÜV SÜD Report on Certificate for ISO 26262 and IEC 61508

� Rhapsody TestConductor Add On Validation Suite : separately available test suite for Rhapsody TestConductor to help in qualification efforts

� Certification kits for the SXF and SMXF real-time execution frameworks



IBM Rational Rhapsody Reference workflow

� Rhapsody Reference Workflow for the development of safety-related software

– provides guidance on how to fulfill functional safety requirements with model-based development methods and tools

– is based on best practices for safety-related projects

– addresses various workflow activities relevant for the development of safety-related software with a special focus on verification and validation to develop safe software28


IBM Software, Rational

29

www.ibm.com/software/rational

29



30

IBM Rational DOORS Next GenerationDOORS concepts improved and much more….

Definition�Rich-text documents�Diagrams: Process, Use Case�Storyboards, UI sketching & flow�Project glossaries�Templates

Collaboration�Review & Approval �Discussions�Email Notification

Visibility�Customizable dashboards�Analysis views�Collections�Milestone tracking & status

Management� Structure, Attributes/Types� Traceability, Filtering, Tags� Baselines, Change History� Reuse (reqs & types)� Reporting Metrics & Doc.

Planning�Integrated planning�Effort estimation�Task Management

Lifecycle� Central requirements, test,

& development repository � Common administration

and role-based user licensing

� Warehouse reporting



Where does Rhapsody ATG fit with DO-178C testing?

� DO-178C and DO-331 address software design, code, and verification

� Verification involves:

– review (test requirement, coverage review, …)

– analysis (automated MISRA C++ compliance, code coverage analysis, …)

– testing activities (mainly requirements based testing)

� TestConductor directly supports many of the required testing activities and analysis activities (requirements based testing, code coverage, model coverage)

� ATG provides more automation, but does not address additional verification methods beyond TestConductor

� Step 1 – define and implement a DO-178C/DO-311 compliant process using Rhapsody, TestConductor, Team Concert

� Step 2 – if step 1 is working, consider using ATG for more automation



� RTCA DO-178B is an objective-based standard applied by FAA (Federal Aviation Administration) for the certification of software in avionics systems.

� Published in 1992, it covers the 5 main processes concerning Planning, Development, Verification, Configuration Management and Quality Assurance.

� DO-178B outlines the objectives to be met, the work activities to be performed for each objective, and the evidence (output documents) to be supplied for each objective (based on criticality level A-E)

Example: RTCA DO-178B

Software Criticality Level

Failure Condition Category

Failure Condition Description Objectives

Level A Catastrophic Conditions which would prevent continued safe flight and landing. 66

Level B Haazardous/ Sever-Major Conditions which would reduce aircraft safety margin/functional capabilities, produce a higher workload to the flight crew or have serious adverse effencts on occupants

65

Level C Major Conditions which would not significantly reduce aircraft safety, crew ability to work under adveser operation or produce discomfort to occupants.

57

Level D Minor Conditions which would not significantly reduce aircraft safety, slight increas in crew workload or produce some inconvenience to occupants

28

Level E No Effect Conditions which do not affect the aircraft operations or crew workload.

0

model based systems and software engineering an overview of the ibm rational solution

Technology

rational systems

rational rational solution

ibm corporation software

rational integrated

software solution

software engineering

ibm corporation innovation

metrics systems