rosas safety days conference fribourg, switzerland, 10-11...

A Development Guardrail from Regulatory and CustomerRequirements to Certified Safety-Critical Embedded Systems

by

Dipl.-Ing. (TU) Peter Hermle, Aerospace Consultant

supported by CUONICS GmbH

ROSAS SAFETY DAYS ConferenceFribourg, Switzerland, 10-11 October 2017

Agenda

Introduction, Key Terms and Definitions

Background

Development Guardrail Key Concepts

CUONICS Implementation Example for Avionics Domain

Advantages of presented Guardrail Approach

Summary and Conclusion

Questions and Anwers

2ROSAS SAFETY DAYS 2017 - "A Development Guardrail" by Dipl.-Ing. (TU) Peter Hermle

Introduction, Key Terms and Definitions


Introduction: Why do we need a Development Guardrail ?

Safety-Critical Embedded Systems are governed by many Safety and Security Norms, Standards and Regulations that in addition to Customer Requirements have to be considered during the development that is done according to the Company Processes


Safety and Security Norms,Standards, Regulations(Regulatory Requirements)

Company Processes

Customer Requirements

„I read all the documents, butI still don‘t know what to do …“ ?!

Focus: Development Guardrail towards Certification

A Guardrail through the

"Document Jungle“

towards

Certification


Certificateissued by

CertificationAgency

OK

Key Terms: Just a quick recap of IEC 61508

SafetyFreedom from unacceptable risk

Functional SafetyPart of the overall safety relating to the Equipment under Control (EUC) and its Control System which depends on the correct functioning of the active (E/E/PE) Safety-Related Systems.

HarmPhysical injury or damage to the health of people or damage to property or the environment.

RiskCombination of the probability of occurrence of harm and the severity of that harm

Acceptable RiskRisk which is accepted in a given context based on the current values of society

Functional Safety GoalPredicted Risk < Acceptable Risk (100% Safety is impossible!)


Cyber / IT Security

Cyber / IT Security Goals

• Confidentiality

• Integrity

• Availability

Threats in the Cyber World

• Cyber Vandalism

• Cyber Crime

• Cyber Espionage

• Cyber Terrorism

• Cyber Warfare


Safety vs. Security: Two sides of the same coin

Safety

Goal: Equipment does not harm people, property or environment

People / Users will normally try to prevent harm

Cyber / IT SecurityGoal: People can not harm Equipment orControl System

People / Users will normally try to cause harm


Definitions

Within this presentation, the following definitions will be used for simplification:

Objectives := Regulatory Requirements from Norms, Standards and Regulations

Requirements := Customer Requirements (including Technical Requirements)


Background


Increase and Change of Requirements and Objectives

Today typically between 10.000 - 100.000 or even more requirements and objectives spread across many different documents -> ("Document Jungle")

Any change of Objectives or Requirements typically generates huge rework effortin development projects due to the many dependencies, leading to time-consuming and costly rework loops


SPEC1 NORM

1 NORM2

STANDARD 1 STANDARD

2 STANDARD 3

Expansion of System Boundaries: „Remote Control“

Past: Isolated Stand-Alone Embedded Systems

Today: Cyber-Physical Systems (CPS) accessible (and attackable) via Internet from around the world

From “WIRED” 07/2015:

Hackers remotely kill a Jeep on the Highway at 70 mph and lateralso cut the Jeep's brakes, letting the SUV slide uncontrollablyinto a ditch

Recall of 1.4 million Jeep vehicles by FIAT Chrysler Automobiles

Cyber / IT Security is a key prerequisite for Functional Safety today !


Expansion of System Boundaries: „Connected“ Passenger Cars


Former Security Scope

DoorLocking

Infotain-ment

Drivetrain

EngineECU

Steering-Sensor

Former Safety Scope

ABS

DoorLocking

New Safety & Security Scope

Expansion to the max: Internet of Things - IoT


Internet of Humans: 2 - 3 Billion Internet of Things: 20 - 30 Billion

Merging Functional Safety and Cyber / IT Security in System Development


SafetyAnalysis

SecurityAnalysis

SafetyGoals

SecurityGoals

SafetyValidation

SecurityValidationHazard

Analysis & RiskAssessment

Safety & Security Concept

FMEA, FTA FMEDA

Attack TreeAnalysis

SafetyArchitecture

SecurityArchitecture

SafetyVerification

SecurityVerification

SafetyTesting

SecurityTesting


CertificationAgency

OK

Automotive Safety: ISO 26262Automotive Security: SAE J3061

Domains with Safety, Security and Certification Demands


Domain Norms, Standards and Regulations

Aerospace / Avionics SAE ARP4761 / 4754, RTCA DO-178 / -254 / -331

Automotive ISO 26262, SAE J3061, ISO/IEC 15504

Critical Infrastructure IEC 61508 / 61513, IT-SiG (Germany)

Industrial, Machinery IEC 61508 / 61511 / 62061, ISO 13849

Medical IEC 62304

Rail EN 50126 / 50128 / 50129

IoT = Internet of Things ISO/IEC 15408, 27001

These are just a few examples, there are many many more for every domain !

Development Guardrail Key Concepts


Development Guardrail Key Concepts Overview

MANAGEMENT of Development within an Integrated Work Environment

Full TRACEABILITY between Objectives, Requirements and Project Models

VISIBILITY OF DEPENDENCIES across all levels of development

DETAILED enough INSTRUCTIONS to developers, testers and QA

so that they really exactly know, what to do,

without prior reading hundreds or thousands of documents


Development Guardrail Key Concept I Model-Based System Development using UML and SysML


CustomerRequirements

SystemRequirements

ItemRequirements

Hardware DesignSoftware Implementation

ItemV & V

SystemV & V

ProductValidation andCertification

Development Process using UML & SysML


CertificationAgency

OK

Other typical Developmentand V&V Tools have to be usedin addition to UML & SysML !

Development Guardrail Key Concept IIBusiness Process Modeling Notation (BPMN) - Eriksson-Penker Extensions


Company Processes include a pre-defined Process Model in SysML with Roles and Links to Objectives

Development Guardrail Key Concept IIIPre-defined Process Model in BPMN with Roles & Links to Objectives


QMS

Norms

Regulations

Standards

Company Processes CustomerProject


System / Item HW / SW Models

Processesin BPMN

Company Processes and Customer Project build an Integrated Work Environment

Development Guardrail Key Concept IVFully bi-directional Traceability

Fully bi-directional Traceability between Objectives, Requirements and Project Models results in much better awareness of dependencies for

• Developers• Verification-Staff• QM-Staff• Auditors• Certification Agencies

“This is how we've done it -and why”


QMS

Norms

Regulations

Standards

Company Processes

Company Processes and Customer Project build an Integrated Work Environment

CustomerProject



Bi-directionalTraceability

Development Guardrail Key Concept V„Atomization“ - Decomposition of Processes

Many Development Processes have similar or even identical Process Steps

• Creating Planning Documents• Configuration Management• Reviews• etc …

By identifying these Process Steps and creating smaller common invocableSub-Processes („Tasks”) from them („Atomization“ ), the usage of Process Modelsand interfaces to other tools can be simplified

By „Atomization“ , Process Steps can be broken down to a level of granularity that also makes it much easier for developers to understand, what they should exactly do.


Process

Sub-Process / Task 1



Development Guardrail Key Concept VICustomized Nomenclature / Vocabulary adapted to Domain


One historical example of an ambitiousengineering project that failed due tothe lack of a common language

Therefore the pre-defined ProcessModel needs to contain definitions forNomenclature and must use the Vocabulary adapted to the Domain

Also the basic language needs to be chosen carefully: • German Automakers love German!• French Automakers love French!• All others try to cope with English …

UML / SysML as„Common Technical Language“ Tower of Babel (1563) by Pieter Bruegel the Elder

Development Guardrail Key Concept VIICommon Configuration Management of both Process and Project


QMS

Norms

Regulations

Standards

Company Processes CustomerProject



Common ConfigurationManagement

Database

CUONICS "Guardrail " Implementation Example for Avionics Domain

Examples and Screenshots from typical Avionics System Developmentusing SAE ARP 4761 / 4754A, RTCA DO-178C / DO-254

and EASA CM-SWCEH-002 / CM-SWCEH-001for the pre-defined Process Model in BPMN


CUONICS Development and V&V Tool Overview



SystemRequirements

ItemRequirements

Hardware DesignSoftware Implementation

ItemV & V

SystemV & V

ProductValidation andCertification

CUONICS Integrated Work Environment Tool Overview


Polarion

SVN

Enterprise Architect (EA)

Developer Local Work

Environment

QM Process& Document

Templates

• Polarion for Requirements, Document & CR/PR Management

• „Ticket system“ with Work Items assigned to Developers & QM

• Apache Subversion (SVN) for Configuration Management

• Extensions via API

• Enterprise Architect (EA) asUML & SysML Tool

• Process Modeling• System, HW/SW Modeling• Supports links between

model elements and file system or any other URL

• Extensions via API

• Protected storage on the intranet• Managed by QM• Change Management via Polarion

• Local Work Environment Copy for Developers

• All files managed by SVN(„Sandbox“)

manages

link between Processes and Customer Project areboth modeled in the same EA tool !

CUONICS Company ProcessesPre-defined Avionics Development Process Model managed by QM


Users that do not need to change the Processes, but only need to view them,can use a read-only Web Interface via Enterprise Architect HTML Export

act Create PSAC

ActivityInitial

ActivityFinal

DO-178C:11.1a) document system ov erv iew

DO-178C:11.1b) Document software ov erv iew

DO-178C:11.1c) Document certification considerations

DO-178C:11.1d) Summarize software life cycle

DO-178C:11.1e) Specify software life cycle data

DO-178C:11.1f) Define schedule

DO-178C:11.1g) Document additional considerations

DO-178C:11.1h) Document supplier ov ersight approach

CUONICS Process Model for DO-178CSoftware Planning Process Activities


References to theapplicable sectionsof RTCA DO-178C

In contrast to a simple drawing tool (e.g. MS-Visio),EA „understands“ the relationships and dependencies between the model elements and can display themconsistently across all diagrams where they appear.

CUONICS Development Life Cycle Data Creation and Requirements Management directly in Polarion from Templates and Work Items

• Templates for DO-178C / DO-254 provided• Documents are created from Work Items• Work Items can be of various Types:

o Headlineso Requirementso Taskso Test Caseso Change Requests (CRs)o Problem Reports (PRs)

• Work Items are assigned to a developmentteam member or to QM (Assignee)

• All work can only be executed if a Work Item has been created & assigned

• Requirements Management also throughWork Items after Customer RequirementsImport


CUONICS Development Life Cycle Data Creationwithin the Integrated Work Environment

32ROSAS SAFETY DAYS 2017 - "A Development Guardrail" by Dipl.-Ing. (TU) Peter Hermle 32

Development Life Cycle Data have • a Representation in EA (1), accompanied by a Process Model (2)• a Template that defines their basic structure (3)• a Polarion Document (4) where the content is

• partly written according to the Process Model (2)• partly composed from existing elements

1

2

3

4

1 23

42

CUONICS System Life Cycle Data Representation in Enterprise Architect (EA)


CUONICS Document Templates: Plans, Checklists


CUONICS Process Model – Invocable Sub-Processes (“Tasks”)Examples from Configuration Management


CUONICS Requirements Management Special FeatureHierarchical View in EA to visualize Requirements / Objective Dependencies


Import

Polarion Requirements View Enterprise Architect (EA) Requirements View

CUONICS Common Objective Clusteringinto Company Objective Matrix


The Company Objective Matrix is arranged from derived Objectives of the various Development Processes providing the fully bi-directional tracability to Objectives of the Avionics Domain

EN 9100 ARP4754A DO-254 DO-178C DO-330

Company Objective

CUONICS Integration of Process and Customer Project


ProcessCustomer Project

CUONICS „Guardrail“ Implementation Example: Mastering the Challengesof Certified Safety-Critical Embedded Systems Development


Challenge Approach Tools

Understand dependencies between various Processes

Create BPMN process models and specific context diagrams

Enterprise Architect

Live the Processes Create Integrated Work Environment and Workflows

Polarion, Enterprise Architect

Avoid Redundancies Reference across all development levels and across all processes

Polarion, Enterprise Architect

Ensure overall ConfigurationManagement

Manage all data with one technology

Apache Subversion (SVN)

Ensure fully bi-directional Traceability

Prefer automation over manual references

Apache Subversion (SVN)Polarion, Enterprise Architect


• Integrated Work Environment: Process & Project can both be managed in the same UML/SysMLTool

• Common Process and Project Modeling allows a seamless Integration between System- / Safety- / Security-, Hardware- and Software-Development and V&V resulting in reduced interfacing problems between all these activities

• Improved project visibility and developer guidance results in easier and better performance of Certification Audits due to bi-directional objective traceability ("This is how we've done it and why")

• Achievable savings in time and cost during development due to "Guardrail" Approach according to Gerald Thonigs, Head of Development at CUONICS GmbH:• Time Savings: -10% up to -40%• Cost Savings: -20% up to -40%

• Lower barrier of market-entry for new or smaller companies into highly regulated domains for Certified Safety-Critical Embedded Systems led by bigger companies with long process experience



Without a proper "Guardrail", Developers are often "lost in the Jungle“

A proper "Guardrail" can save time and cost up to 40%

No Functional Safety without Cyber / IT Security


Questions and Anwers

Thank you for your kind attention!

Any questions?


CUONICS GmbHÄußere Passauer Str. 13794315 StraubingGermany

Phone: +49 (9421) 75307-0 E-Mail: [email protected] Web: www.cuonics.com

Bruckthaler Str. 3084177 GottfriedingGermany

Phone: +49 (172) 9513968 E-Mail: [email protected]

Dipl.-Ing. (TU) Peter HermleAerospace Consultant

45

Contact Information

ROSAS SAFETY DAYS 2017 - "A Development Guardrail" by Dipl.-Ing. (TU) Peter Hermle