Standardized approach to
building reliable embedded software
Sangchul Han
Konkuk University
Agenda
• Building reliable software
– Why standardized approach is necessary?
• Standardization efforts
• Case study – avionics software
– DO-178B
– ARINC 653
Building reliable software
• 표준화된 접근이 필요한 이유
– 높은 신뢰성 요구
• How can you say your software is reliable?
• Ex. A software for ABS.
– If ABS didn’t work well, people might be hurt.
– If there is a bug in ABS of your car, what would you want to do?
• 높은 신뢰성을 요구하는 임베디드 소프트웨어는 하드웨와 같
이 취급됨
– 높은 생산성 요구
• Time-to-market pressure
– 짧은 개발 cycle / 낮은 cost / 높은 기술 요구 사항
• 개방형 표준을 지향
– 신뢰성이 높으면서도 재사용 가능한 소프트웨어
– 다른 소프트웨어와 호환성을 유지해야 함
Standardization efforts in
embedded software
• Automotive industry
– 유럽/미국
• 운영체제: OSEK 표준
• 소프트웨어 플랫폼: AUTOSAR
– 일본
• JasPar
• Japan automotive software Platform architecture
• AUTOSAR에 공동 대응
• TOYOTA, NISSAN, HONDA R&D, 덴소, TOYOTA 쯔쇼
전자
• FlexRay 표준 주도
• 히노마루 OS 개발 추진
• 자동차 엔진 제어용 운영체제 및 공통 제어 SW 플랫폼 개발
추진
Standardization efforts in
embedded software
• Avionics
– ARINC (Aeronautical Radio, Incorporated) 규격
• 미국의 U.S Air Caririers 소유의 비영리 단체로 1929년 설립
• 400 계열 : 장착, 와이어링, 데이터 버스 등에 대한 지침
• 500 계열 : 아날로그 항공전자 장비(예를 들어 B-727, DC-9, DC-10, 초기 모델
인 B-737, B-747, A-300 항공기에 사용)
• 600 계열 : ARINC 700 계열에 특정한 장비를 위해 제정
• 700 계열 : 디지털 항공전자 시스템 항공기에 장착한 장비에 적용하고, 여기에
는 데이터 링크 프로토콜도 포함
• 800 계열 : 네트워크가 지원되는 장비에 적용하고, 여기에는 고속 데이터 통신에
사용하는 광 파이버(fiber optics)를 포함
• 900 계열 : 통합 모듈 또는 네트워크 구조를 가진 항공전자 시스템
– 주요 IT관련 규격
• ARINC 429, 데이터 통신 포맷
• ARINC 600, 커넥터
• ARINC 653, 실시간 운영체제와 그 위에서 동작하는 응용 프로그램 간의 인터페
이스를 규정
• ARINC 763, Aircraft Network and File Server, ORB
임베디드 SW
개발 공정 표준
• DO-178B
– Software Considerations in Airborne Systems
and Equipments Certification
• 1992년 제정 (1985년의 DO-178A에서 개정)
– FAA에서 항공용 SW의 인증을 위해 사용
– DO-178B는 규정이 아님
• objective의 달성 방법은 벤더가 결정
Software level
• 5단계 소프트웨어 기준
– Catastrophic: 추락의 위험을 가지는 고장 위험 수
준
– Hazardous: 성능 또는 안전에 큰 부정적인 요소를
갖거나 물리적인 변형 또는 과도한 업무 부하로
인해 조종사가 비행을 유지할 수 없는 위험 수준
– Major: 심각하나 위험하지 않음 (예: 승객이 다치
진 않았으나 불편함)
– Minor: 고장 상태이나 Major 보다 덜함 (예: 승객
의 불편을 초래하거나 비행 경로 변경 필요)
– No Effect: 안전, 비행 조정, 조종사 과부하에 영향
을 미치지 않음
SW를 어떻게 안전하게 만드는가?
• 표준 프로세스에 따라 objective를 결정함으로써
SW개발의 함정과 실수를 방지하도록 함
– DO-178B 프로세스
•
•
•
•
•
•
•
•
Planning Process
Development Process
Requirements Process
Design Process
Coding and Integration Process
Testing and Verification Process
Configuration and Management Process
Quality Assurance Process
– SW lifecycle process 는 trace 가능해야 함
DO-178B
• SW의 failure 발생 시 심각도에 따라 SW 레벨을
정함
• 각 레벨에 따라 만족해야 하는 objective 결정
– A: 66, B: 65, C: 57, D: 28
Does DO-178B help make S/W
safe?
• How do we know when software is safe?
– We don’t know.
• What is our best guess about software safety?
– When applicable processes have been followed
– When the code has been verified
– When it has been checked, checked, checked,
checked, checked, ……
DO-178B’s basic strategy
• Use of standard processes help avoid the common
pitfalls of S/W development.
Processes in DO-178B
•
•
•
•
•
•
•
•
•
Planning
Development
Requirement
Design
Coding and integration
Testing and verification
Configuration management
Quality assurance
Each process requires pre-defined output
documents.
ARINC 653
• Avionics standard for safe, partitioned
systems
– A specification for an application executive
used for integrating avionics systems on
modern aircraft
– 51 routines: time and space partitioning,
health monitoring (error detection and
reporting), communications via ports
– ARINC 654 OS and applications are typically
certified per DO-178B
APEX (APplication EXecutive)
• ARINC 653 API
– Management of:
• Process, time, partition, buffer, semaphore, event,
blackboard, sampling port, queuing port, error
– Language: C & Ada
ARINC 653 features
• Portability
– Standard API (APEX)
• Reusability
– Certification of standard API
• Modularity
– Removal of H/W and S/W dependency
• Integration of S/W of multiple criticalities
– Each application uses a virtual target of DO178B
– Supports different levels of DO-178B on the
same processor
ARINC 653 RTOS architecture
Partitioning OS
• Partitioned OS
– memory (and possibly CPU time as well) is divided among
statically allocated partitions in a fixed manner.
– make a processor pretend it is several processors by
completely isolating the subsystems.
• Hard partitions
– set up for each part of the system, and each has certain
amount of memory (and potentially a time slice) allocated to
it.
– Each partition is forever limited to its initial fixed memory
allocation
• Process & thread
– Within each partition may be multiple threads or processes, or
both,, scheduled depends on the implementation of the OS.
Secure RTOS partitions
•
Each RTOS partition performs like a stand-alone RTOS
•
Time partitioning
•
Memory partitioning
•
Resource partitioning
– System events in one partition cannot be shared with another partition (except
VM0, root privilege)
– done through a fixed-cyclic time-slice scheduler, which allocates periods of time to
each partition.
– During each time slice, only processes in the assigned partition are permitted to
execute.
– dividing RAM into discrete blocks of non-overlapping physical address space.
– Each RTOS partition is assigned one and only one block of memory.
– Within the partition, the virtual address spaces of various processes are mapped to
memory from the assigned memory block.
– each device can be assigned to only one partition of the RTOS.
•
a fault in a device or its driver will be contained within a single RTOS partition.
– Each partition mounts a RAM-based file system for data storage.
– The file systems are private to the individual partitions and are never shared with
other partitions.
ARINC 653 scheduler
XML-Based Configuration
C-based
Configuration
Data
Certify all together
App 1 App 2 App 3 App 4
Configuration Data
from unqualified tool
C compiler or other
unqualified tool
Other ARINC 653
Operating System
XML-Based
XML Configuration
Data
Certify separately
App 1
App 2
App 3
App 4
Configur
ation
Data
Higher initial development
time, higher certification
cost, higher cost of change
and re-certification
XML-based configuration
data managed by DO-178B
qualified XML  binary
compiler
Test, certify, and re-certify
applications independently
Binary
Qualified
XML Compiler
Configuration Data
(partitions, ports, …) in C,
text, XML, created by
unqualified tool: must test
and certify entire system as
a whole, even for minor
configuration change
and asynchronously
ARINC
653
Result: Lower development
time, lower initial cert cost,
and lower cost-of change and
re-certification
Typical ARINC 653 RTOS features
Strong Partitioning
Time and space partitioning
Multiple APIs
APEX
POSIX subset
Multilanguage (C, C++, Ada)
Legacy
Error management
Health management
Cold/warm restarts: 2s / 100ms
Temporal violation detection
Certification audit
DO-178B certification evidence
Multiple certification levels on
one system
Robust partitioning
Priority preemptive scheduling Slack time scheduling
Rate Monotonic
Certification tools
Configuration created from XML
결론
• 기술 동향
– 구성 요소와 응용 범위가 넓어지고 있으며, 다학제적 (multidisciplinary) 성격이 강해짐
– 네트워크 연결성의 고려
– 지금까지 analog control 로 기능하던 physical system 의 digital
화와 SW 에 의한 기능 대체
• 표준화 동향
– 제조업 중심으로 진행 - SW의 부품화
– Open standard 채택 경향
• 극복해야 할 문제점
– SW 고신뢰성 확보
– 동적으로 변화하는 physical system에 대한 재구성 가능한 서비
스 제공
– Failure 발생 시의 대처 방안