ARINC-653 and Virtualization Concepts for Safety- Critical Systems

SAVUNMA SANAYİİ MÜSTEŞARLIĞI 

Kalite – Test ve Sertifikasyon Daire Başkanlığı 

INTERAKTİF KOKPİT GÖRÜNTÜ SİSTEMLERİ ve 

SERTİFİKASYONU 

için YAZILIM YAKLAŞIMLARI 

ARINC 653 / DO-178C ve ARINC 661 

Konferansı 

30 Kasım 2012, Ankara 

ARINC-653 and 

Virtualization 

Concepts for Safety- 

Critical Systems 

Alex Wilson, Wind River, Director, EMEA Aerospace and Defence

SAVUNMA SANAYİİ MÜSTEŞARLIĞI 

Kalite – Test ve Sertifikasyon Daire Başkanlığı 

INTERAKTİF KOKPİT GÖRÜNTÜ 

SİSTEMLERİ ve SERTİFİKASYONU 

için YAZILIM YAKLAŞIMLARI 

ARINC 653 / DO-178C ve ARINC 661 

Tarih : 30 KASIM 2012 

Saat : 09:00-17:45 

Yer : SSM Sosyal Tesisleri 

PROGRAM : 

09:00 - 09:10 Açılış ve Konuşmalar 

09:10 - 09:30 Challenges Facing Aerospace and Defense Suppliers 

Alex Wilson, Wind River Director, Aerospace and Defence 

09:30 - 11:00 ARINC-653 and Virtualization Concepts for Safety-Critical Systems 

Alex Wilson, Wind River Director, Aerospace and Defence 

11:00 - 11:15 Çay-Kahve Molası 

11:15 - 13:00 Getting Ready for DO-178C 

Bernard Dion, Ph.D., Esterel Technologies Chief Technical Officer 

13:00 - 14:00 Yemek Arası 

14:00 - 15:00 Introduction to ARINC 661 Standard 

Cockpit Display System Interfaces to User System 

Vincent Rossignol, Esterel Technologies Product Marketing 

Manager 

15:00 - 15:15 Çay-Kahve Molası 

15:15 - 17:30 An Implementation of ARINC 661 Standard 

Vincent Rossignol, Esterel Technologies Product Marketing 

Manager 

17:30 - 17:45 Kapanış Konuşması – Soru ve Cevaplar 

Kayıt : event@tektronik.com.tr 

En iyisinin teminatı

ARINC-653 and 

Virtualization Concepts for 

Safety-Critical System

Why virtualize? 

Consolidation 

(Merging or reducing several systems) 

Performance 

(Increase speed and functionality in existing system) 

Separation 

(Split existing functionality for safety and/or security) 

11 

| © 2012 Wind River. All Rights Reserved.

Virtualization and Partitioning 

Virtual Machine 1 Virtual Machine 2 

Application 1 

Application 2 

• Cores 

• Memory 

• Devices 

Guest Operating System 1 

Guest Operating System 2 

Virtual Machine Monitor (Hypervisor) 

Single or Multi-core Processor 

12 


Avionics Consolidation Trend 

1980s 1990–2000 2010+ 

Multicore Platform 

App 

App App App 

Virtualization Layer 

Core 

Core Core Core 

• One box 

• One function 

• One OS 

• One safety/security level 

• Federated systems 

• One board 

• Multiple functions 

• One OS 

• Multiple safety/security levels 

• Integrated Modular Avionics 

• One die 

• Multiple functions 

• Multiple OS 

• Multiple safety/security levels 

• Multi-core integration 

13 


Virtualization and Avionics 

Avionics Bus: 

• ARINC 429/629 

• ARINC 664 

• MIL STD 1553 

• SAE AS6802 

Federated Avionics Computer: 

Inertial Reference System 

Integrated Modular Avionics (IMA) Computers: 

• Flight Management 

• Mission Computer 

• Displays (ARINC 661) 

• Navigation 

• Engine Monitoring 

• Fire Control 

• Stores Management 

• Targeting Computer 


Flight Controls 


Engine Controls 


HUD/HDD (ARINC 661) 


Weapons Controls 


Sensor Systems 

14 


Federated and Integrated Modular Avionics 

Federated 

Advantages 

• High performance 

• Independence of design and 

certification 

• Well-understood methodology 

• Established supply chain 

Challenges 

• Greater size, weight, and power 

(SWaP) requirements 

– Each function is separate LRU 

• Less software reuse 

• Less portability, less modularity 

• Cannot scale into larger platforms 

IMA 

Advantages 

• Lower SWaP requirements 

– Multiple functions on single LRU 

• Better software reuse, refresh 

• Better portability, modularity 

• More efficient platform certification 

Challenges 

• Greater complexity of system 

integration 

• Greater complexity of design and 

certification 

• Less experienced supply chain 

Radar 

Flight 

Management 

Graphics 

Flight 

Management 

Radar 

Graphics 

Time and Space Partitioning 

ARINC 653 Operating System 

ARINC 429 

15 


ARINC 653 for Integrated Modular Avionics 

• Goal: Reduce size, weight, and power (SWaP) requirements 

• ARINC 653: Industry specification for Integrated Modular Avionics (IMA) 

• Includes API of 56 routines 

– Time and space partitioning 

– Inter- and intra-partition communications (IPC) 

– Health monitoring (error detection and reporting) 

• ARINC 653 OSs and applications are typically certified to DO-178C / ED-12C 

• RTCA/DO-297: Integrated Modular Avionics Development, Guidance and Certification, 

Shared set of flexible, reusable, and interoperable hardware and software resources 

Integrated Modular Avionics (IMA) 

Flight 

Management 

Radar 

Graphics 

Time and Space Partitioning 

ARINC 653 Operating System 

16 


VxWorks 653 DO-178C and ED-12C 

Level A Certification Evidence Package 

• Plan for Software Aspects of Certification (PSAC) 

• Software Quality Assurance Plan 

• Software Configuration Management Plan (SCMP) 

• Software Development Plan (SDP) 

– Software requirements standards 

– Software design standards 

– Software coding standards 

• Software Verification Plan (SVP) 

• Software Requirements Specification (SRS) (7,000 

requirements) 

• Software Design Document (SDD) 

• Software Life Cycle Environment Configuration Index 

(SECI) 

• Traceability Matrix 

• Software Development Folder 

– Design reviews 

– VxWorks 653 source files and binary code 

– Code reviews (40,000 LOC) 

– Test reviews (7,500 tests) 

– Functional tests (270,000 LOC) 

– Coverage results (object level) 

• Software Accomplishment Summary (SAS) 

• Tools Qualification Documents (TQD) 

– Test Harness for VxWorks 653 

– VerOcode, VerOLink, VeroSource-A, VeroTrace 

– WindSH 

2.9GB sealed DVD with certification artifacts 

and more than 70,000 hyperlinked files 

17 


VxWorks 653 

The Avionics Platform of the Future 

• First Flight: December 2010 

• FAA Certification: September 2011 

• GE Common Core certified to DO-178B Level A 

• Eliminated over 100 different LRUs 

• 17 Boeing suppliers, dozens of teams 

• DO-297 used for multi-vendor integration / re-use 

November 2012: VxWorks 653 leads the IMA industry with 

over 270 projects, used by over 150 customers in over 55 aircraft 

Photo by LongBachNguyen.com All Rights Reserved. 

18 


The ARINC 653 standard 

• ARINC 653 Specification First Published 

• ARINC 653P1-3 (Part 1 Supplement 3 Required Services) 

– ARINC 653 partition management 

– Cold start and warm start definition 

– Application software error handling 

– ARINC 653 compliance 

– Ada and C language bindings 

• ARINC 653P2-2 (Part 2 Supplement 2 Extended Services) 

– Including File System, Logbook, Service Access points… 

• ARINC 653P3 (Part 3 Conformity Test Specification) 

– Supplement 1 in progress 

• Added ARINC 653 Part 4 (Subset Services) 

• New Proposal 

– Part 0 – Overview of APEX Services 

– Part 5 - Non-API Related O/S Capabilities (working title) 

19 


ARINC 653 Scheduling 

• Standards-based virtualization approach 

– "Virtual machine" approach as described in DOT/FAA/AR-99/58, 

Partitioning in Avionics Architectures: Requirements, Mechanisms and 

Assurance, by John Rushby 

– Virtualization enables applications to run on partition OSs 

Partition 1 Partition 2 

Partition OS 

Partition OS 

Partition 1 Time Slice 

Partition 2 Time Slice 

Time 

20 


IMA in the Real World - Lessons Learned 

• IMA systems can be extremely complex: 

– Large number of applications: 10+ 

– Large application: 2,000,000+ lines of code, 4-8 MBytes 

– Large configuration data: 50,000+ configuration entries 

• Complexity must be managed to be successful 

– Roles and responsibilities have to be defined 

– Role activities have to be decoupled 

• Development cycles are shorter and shorter 

• Cost of change must be low 

– Introducing a change should have a low impact, even during the 

certification cycle 

– Must be scalable 

21 


So what is DO-297 / ED-124? 

“Integrated Modular Avionics (IMA) Development 

Guidance and Certification Considerations” 

• Purpose: 

“..provides guidance for IMA developers, integrators, applicants, and 

those involved in the approval and continued airworthiness of IMA 

systems. It provides specific guidance for the assurance of IMA 

systems as differentiated from traditional federated avionics” 

• Results of joint US/EU Study RTCA SC-200 and EUROCAE WG-60 

• Defines roles and responsibilities – Certification applicant, Systems 

Integrator, Platform Provider, Application Developer 

• References RTCA DO-178B (EUROCAE ED-12B) and ARINC 653 

22 | © 2012 Wind River. All Rights Reserved.

Certification of IMA system 

From DO-297 : 

“Six tasks define the incremental acceptance of IMA systems in the certification process:” 

– Task 1: Module acceptance 

– Task 2: Application software or hardware acceptance 

– Task 3: IMA system acceptance 

– Task 4: Aircraft integration of IMA system – including Validation and Verification 

– Task 5: Change of modules or applications 

– Task 6: Reuse of modules or applications 

Key implementation and certification challenges:- 

• How to change application or configuration entities without affecting the entire 

system? 

– Without requiring re-testing or re-certification of other independent entities 

• How to reuse applications from one IMA project on the next IMA project? 

– Without having to re-write and re-test the entire application 


Benefits of incremental certification 

• Development of applications independently 

• Ability to modify an application 

• Re-use of applications 


DO-297/ED-124 certification stakeholders 

Certification Authority 

– Organization that grants approval on behalf of the state(s) responsible for the aircraft/engine 

certification 

Certification Applicant 

– Responsible for demonstrating compliance to applicable aviation regulations 

– Seeking TC, Amended TC, Supplemental TC or Amended STC 

System Integrator 

– Integrating the “platform” and “applications” to produce “IMA System” 

– System Configuration, Resource allocation, IMA V&V 

Platform Supplier 

– Provide processing hardware and software resources (including the core software) 

– Specify interfaces, shared resources, configuration tables 

– Platform V&V 

Application Supplier 

– Develops “Hosted” applications and verifies on “platform” 

– Specifies external interfaces and resource requirements of application 


Independent software delivery / DO-297 

Supplier 1 Supplier 2 Supplier 3 Supplier 4 

IMA System 

Integrator 

User 

Mode 

Flight 

Management 

Application 

Level A 

Radar 

Application 

Level B 

Graphics 

Generator 

Application 

Level C 

Display 

Application 

Level D 

Application 

Suppliers 

ARINC 653 

Partition OS 

POSIX 

Partition OS 

VxWorks 

Partition OS 

Ada/Java 

Partition OS 

Platform 

Supplier 


Application Executive 

Architecture Support 

Package (ASP) 

XML Configuration Data 

Board Support 

Package (BSP) 

Kernel 

Mode 

Hardware 

26 


XML Table Generator for 

Review of Configuration Data for Credit 


Supplier 

XML Tables 

XML Config 

File 

System 

Integrator 

XML Tables 

XML Config 

File 

FMS 

XML Tables 

XML Config 

File 

Application 

Suppliers 

Nav 

XML Tables 

XML Config 

File 

Display 

XML Tables 

XML Config 

File 

XML Compiler/Checker 

DO-178 Qualified Development Tool 

XML Business 

Rules 


Data 

Schedule 

Tables 

HM Table 

HM Table 

HM Table 

FMS 

Nav 

Display 

Reviewers, DERs and Certification Authorities 

27 


New FAA Policy: 

Reusable IMA Components 

• Advisory Circular AC 20-170*, October, 2010 

– “Integrated Modular Avionics Development, Integration, 

Verification and Approval Using RTCA DO-297 and TSO C153” 

• Technical Standard Order C153**: IMA Hardware Elements 

– Allows for reuse of previously “accepted” IMA components 

• Applications, OSs and hardware 

• Software accepted by the FAA as meeting DO-297 

objectives across IMA platforms 

– Allows for “portability” of certification effort to other products 

without full re-verification of unmodified software components 

* http://www.faa.gov/regulations_policies/ 

** http://rgl.faa.gov/Regulatory_and_Guidance_Library/rgTSO.nsf/Frameset?OpenPage 

28 


IMA Acceptance Supports Multiple 

Approvals by reducing time/effort 

IMA Cabinet with 

Applications, TSO 

C153 Hardware and 


Same Hardware and 

OS reused in 

different 

configurations 

Certified applications 

approved in different 

configurations using 


29 


What is Multi-Core? 

• Architecture where a single physical 

processor contains the core logic of two 

or more processors 

• Packaged into a single integrated circuit 

(IC) called a die 

– Can also refer to multiple dies packaged 

together 

• Multi-core enables the system to 

perform more tasks with a greater 

overall system performance 


Why use Multi-core in Avionics? 

• Embrace the future! 

• Demand for more power 

• Pervasiveness of multi-core silicon 

• Virtualization for Multi-OS designs 

• Ability to separate applications 

– Security and safety separated too 


Multicore configurations 

Single Core 

“Traditional” 

OS 

Core 

Core Virtualization 

OS OS 

Hypervisor 

Core 

SMP 

Unsupervised AMP 

Supervised AMP (sAMP) 

Multi-core 

OS 

Core 1 Core 2 

OS 

Core 1 

OS 

Core 2 

OS OS 

Hypervisor 

Core 1 Core 2 

32 


Safety & multicore 

• Consolidation of safety-critical applications through IMA 

– ARINC 653 dominant 

• Consolidation of uni-processor systems onto multicore 

• Suitable approaches for safety-critical multicore systems 

– SMP: 

• Pros: attractive model 

• Cons: loss of determinism in multicore environment 

– AMP: 

• Pros: can be used with a Hypervisor to partition shared resources, 

support multiple applications at different levels of criticality 

• Cons: still need to prevent coupling through shared resources 


Typical Single Core architecture 

- ARINC 653 

User 

Mode 

Flight 

Management 

Application 

Radar 

Application 

Graphics 

Generator 

Application 

Display 

Application 

Level A 

Level B 

Level C 

Level D 

ARINC 653 

Partition OS 

POSIX 

Partition OS 

VxWorks 

Partition OS 

Ada/Java 

Partition OS 


Application Executive 

Architecture Support 

Package (ASP) 

XML Configuration Data 

Board Support 

Package (BSP) 

Kernel 

Mode 

CPU 

Ethernet 

GPU 

Memory, other I/O 

34 


Multi-core: 

Electronic Flight Bag Use Case 

DO-178 Level A 

DO-178 Level C 

DO-178 Level E 

DO-178 Level E 

App 1 

Server App 

VxWorks 

App 2 

Server App 

Linux 

App 3 

Server App 

OS TBD 

App 4 

Server App 

Android 

Hypervisor 

Core 1 Core 2 Core 3 

Ethernet 

GPU 

Flash 


Typical IMA Design: 

Hardware and Software 

Typical Hardware 

Modules 

Typical Software 

Modules 

Common 

Hardware 

Back Plane 

Power Supply 

CPU & Memory 

Real Time Executive 

Built-in Test 

On-board 

Maintenance 

System Protocol 

Common 

Software 

Data Bus 

I/O Processing 

Application 

Specific Software 

Application 

Specific Hardware 

I/O 

Application 

Shaded areas show potential shared resources 

36 


Safety Considerations 

Some Challenges to Multiple Criticalities 

– No policies and guidance 

– Different multi-core implementations 

– Shared caches 

• Loss of determinism, cross channel coupling 

– Shared bus contention 

• Loss of determinism, cross channel coupling 

– Exception redirection 

• Exceptions may be directed to one core 

– Time management 

• Clock interrupt may be directed to one core 


VxWorks Safe & Secure Platform 

Operating Environments 

Development 

Lifecycle Solutions 

Wind River Professional Services 

Wind River Global Support 

VxWorks 

Cert 

Incl APEX 

Real-Time 

Hypervisor 

Profile 

VxWorks 

Wind River 

Linux 

Separation Profiles 

Safety 

v 

Separation 

Profile 

ARINC 653, DO-178C, IEC 61508 

Other 

OS 

Security 

Separation 

Profile 

MLS/CDS 

Wind River 

Simics 

Wind River 

Test 

Management 

Wind River 

Workbench 

Architecture Support: Single and Multicore 

38 


Summary 

• Trends 

– Consolidation 

– Interoperability 

– Regulatory 

• ARINC 653 Standard 

• DO-297 / ED-124 

• Multicore 

• Safe and Secure Platform 

39

ARINC-653 and Virtualization Concepts for Safety- Critical Systems

Create successful ePaper yourself

Delete template?

Save as template?