METHODS AND LESSONS LEARNED FROM AEROSPACE SYSTEMS

CS Communication & Systems Inc / 1This document is the property of CS Communication & Systems Inc. and cannot be communicated or disclosed without CS Communication & Systems Inc.’s approval. It contains no technical data subject to the ITAR or EAR regulations

DESIGNER, INTEGRATOR, OPERATOR OF MISSION CRITICAL SYSTEMS c-s-us.com

METHODS AND LESSONS LEARNED FROM AEROSPACE

SYSTEMS

CYBERSECURITY MEETS FUNCTIONAL SAFETY SYMPOSIUM 10/17/2018

Presenter:

Amine SmiresSenior Sales [email protected].: +1 (514) 513-9375

CS Communication & Systems Inc / 2This document is the property of CS Communication & Systems Inc. and cannot be communicated or disclosed without CS Communication & Systems Inc.’s approval. It contains no technical data subject to the ITAR or EAR regulations / 2

WHO WE ARE


CS GROUP OVERVIEW – KEY FIGURES

Defense, Security & ATM45%

% Revenue

Space16%

Energy & Industry12%

Embedded Systems &

Software 27%

MAIN CUSTOMERS

France72%

Europe 13%

North America14 %

% Revenue

Others1%

180 MUS$in revenues

1800employees

1440in France

360Abroad

BREAKDOWN BY GEOGRAPHY & SECTOR


OUR CUSTOMERS AND THEIR CHALLENGES

Markets that we serve

Our customers design systems & subsystems

That include mission & safety critical embedded software

Such as Engine Controls, ADAS, Autonomous Driving, and more...

Typically Tier1 and Tier 2 suppliers to

› The aeronautics, defense, space, and automotive industries.

Challenge faced by our customers

Developing such critical systems requires

Advanced skills linked to industry standards and cutting-edge methodologies

Variable development throughput linked to product development cycles

Within ever shrinking budgets and development schedules


CS NORTH AMERICA OFFERING

Expertise in embedded software development, validation, and verification

› ISO 26262 (hazards, risks, ASIL, safety cases) > Model-based Design

› J3061 (Cyber) > Formal Methods

› Automotive Systems Engineering (requirements, controls dev & validation)

A significant and on demand engineering capability

› Onsite consultants / experts, or

› Remote turnkey program delivery with

▪ 150 engineers in Canada, 20 in the USA

▪ 170 in Romania & a pool of expertise with 390 in France

› With flexible business models to meet your expectations (T&M, FFP…)

Advanced test tools to speed-up and lower ongoing costs of the activities

› NADIA (test script generator based on natural language)

› Test benches (HIL, SIL, Processor in the loop...)

After-market

› Embedded software flashing


SOFTWARE & SYSTEMS LOCAL AND OFFSHORE CAPACITY

OFFSHORE CENTER:

Craiova (Romania)

Possibility to use and manage offshore partners

150

20

140

FRONT OFFICE CENTERS:

Montreal and East HartfordOwn Program Governance

200

210 Full-Time Employees in

North America

340 Full-Time Employees Offshore

5

Vancouver :

Safety and Cybersecurity

Activities


SIMILARITIES BETWEEN AEROSPACE AND AUTOMOTIVE WORLDS


WHY ARE WE HERE

We must find errors early in the process


AEROSPACE INDUSTRY

In the aerospace industry, we are governed by several standards to

ensure:

› We have processes and procedures in place so that systems, software

and hardware are uniform and reproducible

› We have standards, which from the start ensure that all requirements are

carefully constructed and decomposed

› All requirements are traceable and flow down

› All software and hardware are driven from these requirements

› All software and hardware are built against these requirements alone

› All software and hardware are tested against these requirements

› All system functionality is verified and validated at the appropriate levels


INTEGRATED SET OF AEROSPACE GUIDANCE DOCUMENTS

Quality & Process

(AS 9100)


AEROSPACE VERSUS AUTOMOTIVE MAPPING

Quality and Process – AS9100

System Safety – ARP4761

System Assessment – ARP4754

Hardware Design Assurance – DO254

Software Design Assurances – DO-178

Automotive SPICE

ISO26262 – Part 3

ISO26262 – Part 4

ISO26262 – Part 5

ISO26262 – Part 6

Guidelines and Specifications


SOFTWARE CRITICALITY LEVELS

Level A, Catastrophic - Failure may cause multiple fatalities, usually with

loss of the airplane.

Level B, Hazardous - Failure has a large negative impact on safety or

performance, or reduces the ability of the crew to operate the aircraft due to

physical distress or a higher workload, or causes serious or fatal injuries

among the passengers.

Level C, Major - Failure significantly reduces the safety margin or

significantly increases crew workload. May result in passenger discomfort (or

even minor injuries).

Level D, Minor - Failure slightly reduces the safety margin or slightly

increases crew workload. Examples might include causing passenger

inconvenience or a routine flight plan change.

Level E, No Effect - Failure has no impact on safety, aircraft operation, or

crew workload.

DO-178C Design Assurance Levels


AEROSPACE VERSUS AUTOMOTIVE LEVELS

Catastrophic – DAL A

Hazardous – DAL B

Major – DAL C

Minor – DAL D

No Effect – DAL E

ASIL – D

ASIL – B/C

ASIL – A

ASIL - QM

System Criticality Levels


AIRBORNE SOFTWARE STANDARD VS ROAD VEHICLES

Airborne Software Automotive Software


V-CYCLE COMPARISON

DO-178C

ISO 26262


DO-178C OBJECTIVES VS ISO 26262


FADEC VS ECU

FADEC ECU

Fail operational Fail operational (at least for autonomous vehicles)


SIMILARITIES BETWEEN AEROSPACE AND AUTOMOTIVE WORLDS


AEROSPACE TESTING STRATEGY APPLIED TO ADVANCED AUTOMOTIVE


SYSTEM DEVELOPMENT SEQUENTIAL TESTING

Test Conduct Readiness Review

Minimum Gate Testing

System Level Testing

Requirements-based Testing


TESTING METHODS – FAIL OPERATIONAL

Redundancy Mode

In Redundancy Mode, the system must continue to work properly. The system provides

an alternative to the failure detected. The type of failure can be:

› Loss of communication, loss of sensor signals

› Actuator System Fault

› System component not available (e.g., power failure)

As these system failures are expected, alternative operating modes are provided. To

verify the system behavior during Redundancy Mode, each expected failure is injected

into the system and the behavior is analyzed to ensure that the system continues

working without perturbation.

The verification activities consists of:

› The transition between normal operation and Redundancy Mode is performed

without interruption (e.g., channel switchover)

› The system behavior has the same performance (response time, precision…)



Degraded Mode

In the case of the loss of critical function, the system must continue operating safely and

within the defined failure conditions category. The system operation is performed with

the compromise of loss of performance and increased crew workload.

Verification activities verify that:

› The transition between operating mode (normal to critical mode) is performed as

per the system requirement (might need pilot’s actions)

› The failure annunciation is propagated correctly in the global system (vehicles,

aircraft…)

› The system transitions into an acceptable behavior for a minimum duration of

time (e.g., allows time for the pilot to land the aircraft).


Par

am

eter

val

ue

Time

Operation Mode

Par

am

eter

val

ue

Time

Operation Mode


Example Redundancy Mode / Degraded Mode

Par

am

eter

val

ue

Time

Operation Mode

Re

du

nd

ancy

De

grad

ed

Normal Operation

Redundancy Mode

Degraded Mode


TESTING METHODS – FAULT INJECTION TESTING

Fault Injection Testing is used to introduce faults into the system

and to determine the effect on system behavior.

Failure Mode and Effect Demonstration (FMED) testing

› Demonstrate the system behavior for every single point interface failure

▪ Open/Short circuit

▪ Loss of communication

Inject memory faults

Communication Protocol Failure (CANBUS)

› Loss of data message (timeout, validity bit, corruption of messages,…)

Special software

› Small modifications applied to the released software for testing purposes

› Used to verify robustness of the software in abnormal operation


SOFTWARE TESTING OBJECTIVE

Requirement-based Testing

Demonstrate the ability of the system to respond in a normal

operation mode:

› Functional behavior

› State transition

› Dynamic behavior

Simulate abnormal operation and demonstrate the ability of the

system to recuperate from abnormal inputs and conditions (i.e.,

robustness of the software):

› Provoke not allow state transition

› Hazardous behavior (over-temperature, over-speed,…)

Achieve test coverage analysis


TEST COVERAGE ANALYSIS

Requirement Coverage Analysis

Structural Coverage Analysis

Determine which code structure was not exercised by the requirements-based test procedure:

› Missing or incomplete requirements

› Not justified deactivated code

› Extraneous Code (e.g., dead code)

Any lack of coverage needs to be justified and the effect on the system must be

assessed for safety and security.


FORMAL METHODS


FORMAL METHODS

Formal methods are mathematically-based techniques for the specification,

development and verification of software aspects of digital system

Reduce costs by finding errors earlier and reducing amount of conventional

testing

Functional safety (part 3)

› hazard identification, risk assessment and ASIL determination

› development of the functional safety concept

› specification of functional safety requirements

System level (part 4)

› refinement of the functional safety concept into the technical safety concept

› specification of technical safety requirements

› safety validation

Software level (part 6)

› disciplined specification, design, implementation

and verification of real-time embedded software


STANDARDS

Required or recommended by standards and other guidance such as

ISO 26262

ISO 26262-6


COST REDUCTION

The decision to use formal method does not need to be driven only by

a requirement to comply with a standard

Judicious use of formal methods has the potential to reduce costs by

finding errors earlier and reducing amount of conventional testing


HOW DOES IT WORK?

"model checking" is one of several approaches to formal analysis

e.g., Safety properties


LESSONS LEARNED


LESSONS LEARNED

Have the verification processes start in parallel

Take credit at the highest level of requirements possible

Add “Break-It” testing to system test to cover robustness

System tests can provide great coverage of the functionality of the entire system as well as individual components

Everything starts with requirements

GOOD REQUIREMENTS = GOOD TESTS = GOOD PRODUCTS

CS Communication & Systems Inc / 34This document is the property of CS Communication & Systems Inc. and cannot be communicated or disclosed without CS Communication & Systems Inc.’s approval. It contains no technical data subject to the ITAR or EAR regulations

CS Communication and Systems Canada

3333 Boulevard de la Côte Vertu,Montréal, Québec, Canada

Amine SmiresSenior Sales ManagerEmail: [email protected].: +1 (514) 513-9375

www.cscanada.ca

CS Communication & Systems, Inc.

222, Pitkin Street – suite 123East Hartford, CT 06108

DESIGNER, INTEGRATOR, OPERATOR OF MISSION CRITICAL SYSTEMS c-s-us.com

THANK YOU

Documents

METHODS AND LESSONS LEARNED FROM AEROSPACE SYSTEMS