Transcript Standardsx
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 발생 시의 대처 방안