Introduction to DeosRTEMS A FACE Safety Base Operating

Introduction to Deos/RTEMS: A FACE Safety Base Operating System Solution Gedare Bloom Howard University FSW 2016 Pasadena CA Joel Sherrill OAR Corporation Gary Gilliland DDC-I, Inc.

Open Group Future Airborne Capability Environment (FACE) • Aviation-focused professional group formed in 2010 to define an open avionics environment • "Voluntary Consensus Standards Body" as defined by the National Technology Transfer Act and OMB Circular A-119 • Facilitates US government participation • Approximately 90 member organizations • Promotes a competitive open market of portable and reusable software components http: //www. opengroup. org/face/consortium

FACE Architecture

FACE OSS Profiles Profile Multiprocess Multithreaded ARINC 653 Number of POSIX Methods Security No Yes 136 Safety Base No Yes 246 Safety Extended Yes Yes 335 General Purpose Yes Optional 812 • Profiles are designed for different levels of criticality • Smaller profiles reflect RTOS configurations that have passed safety certification reviews

Example Differences Between FACE OSS Profiles • General Purpose is only profile to include: • stdin, stdout, and stderr • wide character support • full math library • Safety Base is typical of many embedded systems • does not allow deletion of objects or free() • application likely to never exit • Security is typical of information gateways • does not include FILE * methods • focus is device I/O

FACE Safety Base: ARINC 653 Requirements for Conformance 1. ARINC 653 Part 1: All services associated with Avionics Application Software Standard Interface Part 1 – Required Services 2. Services associated with the following categories of Avionics Application Software Standard Interface Part 2 – Extended Services: a) File System b) Sampling Port Extensions c) Memory Blocks Satisfied by Deos 653 Runtime Library

FACE Safety Base: POSIX Requirements for Compliance • FACE Safety Base POSIX profile has 246 APIs • Initial audit of RTEMS identified 8 missing methods. Most of these have subsequently been added: POSIX API Function Status pthread_condattr_getclock() Added. Available at rtems. org. pthread_condattr_setclock() Added. Available at rtems. org. mmap() To be added to git master December 2016 shm_open() To be added to git master December 2016 pthread_setschedprio() Added. Available at rtems. org. posix_devctl() (per POSIX 1003. 26) Under development pthread_getconcurrency() Added. Available at rtems. org. pthread_setconcurrency() Added. Available at rtems. org. Satisfied by RTEMS

Status of RTEMS vs. FACE POSIX Security Profile Number of POSIX Methods RTEMS - no networking RTEMS - with networking 161 142 methods or 88% 159 methods or 99% Header • devctl. h • sys/mman. h Missing Methods (with networking) posix_devctl shm_open Subset of Profile Targeted for FACE Conformance

Status of RTEMS vs. FACE POSIX Safety Base Profile Number of POSIX Methods RTEMS - no networking RTEMS - with networking 249 227 methods or 91% 247 methods or 99% Header • devctl. h • sys/mman. h Missing Methods (with networking) posix_devctl shm_open Profile Targeted for FACE Conformance

Status of RTEMS vs. FACE POSIX Safety Extended Profile Number of POSIX Methods RTEMS - no networking RTEMS - with networking 335 302 methods or 90% 324 methods or 96% Header Missing Methods (with networking) • devctl. h posix_devctl • spawn. h all 9 • sys/mman. h shm_open Will Align With Profile but Is Limited to a Single POSIX Process

Status of RTEMS vs. FACE POSIX General Purpose Profile Number of POSIX Methods RTEMS - no networking RTEMS - with networking 815 682 methods or 84% 734 methods or 90% Header Missing Methods (with networking) • devctl. h posix_devctl • fenv. h all 11 • inttypes. h imaxdiv, wcstoimax & wcstoumax • math. h acoshl, acosl, asinl, atan 2 l, atanhl, coshl, erfcl, exp 2 l, expm 1 l, fdiml, fmodl, frexpl, ilogbl, ldexpl, lgammal, llroundl, log 10 l, log 1 pl, log 2 l, logbl, logl, lroundl, modfl, nextafterl, nexttowardf, nexttowardl, powl, remainderl, remquol, scalblnl, scalbnl, sinhl, & tgammal • spawn. h all 21 • sys/mman. h mlock, mlockall, msync, munlockall, shm_open, & shm_unlink • sys/select. h pselect • sys/socket. h sockatmark • unistd. h confstr

FACE Conformance Challenge • FACE Safety Base Conformance requires both ARINC 653 and POSIX interfaces • RTEMS had robust POSIX support, no ARINC 653 • Deos had mature ARINC 653 support, no POSIX • Neither alone was capable of meeting the requirements for FACE Safety Base

FACE Conformance Approach • Address technical requirements • Deos provides the ARINC-653 interfaces • RTEMS provides the POSIX interfaces • Provide robust, mature combined solution • Deos has 18 years of certification experience • RTEMS has 27 years of RTOS experience in space and military domains • Deos+RTEMS leverages strengths of both RTOSs to satisfy the FACE Safety Base OSS profile

Deos+RTEMS FACE Concept ARINC-653 Runtime OS Portable Components Segment TS OS POSIX Runtime OS Platform-Specific Services Segment IO TM OS Certifiable Real-time Operating System I/O Services Segment Health Monitoring Device Driver Operating System Segment TS Transport Services Segment

Deos High-Level Architecture Target Software Application 1 Application 2 Partition 3 Partition 2 Partition 1 Partition 5 Partition 4 User Mode Device Drivers Graphics Driver library Network Driver library USB CAN Audio Driver library User Space Kernel Space Interrupts Deos kernel I/O Registry I/O Interrupts PAL Target Hardware Application hardware (I/O devices, Serial buses, etc) CPU Platform hardware (RAM, flash, timer, interrupt) Graphics chipset RAM Ethernet chipset

RTEMS High-Level Architecture

Deos+RTEMS Architecture POSIX Partition Deos 653 Partition Deos RMA Process POSIX User Executable 653 User Executable POSIX API Library and scheduler ARINC 653 P 1 API and scheduler TCP/IP (LWIP) RTEMS/Deos Adapter IOI Lib User Kernel Shared Memory Deos API Shared Memory Deos Kernel PAL Deos Registry with WAT Target System Hardware and CPU

Integration Challenges 1. Adapt RTEMS for paravirtualized environment • Always assumes kernel mode even in user app • Device driver responsibility shared by (user) BSP • Ensure behavior and performance maintained • Solution: Add Deos paravirtualization adapter which uses Deos for supervisor mode services and IO 2. Add missing POSIX services • Really a conformance need. If they had been used by apps, RTEMS would have already had them • Solution: Implement the missing services

Integration Challenges 3. Development Tools • RTEMS: GNU tools on *NIX and Windows • Deos: GNU tools on Windows Eclipse-based IDE • Solution: Provide pre-built RTEMS tools which are integrated into Open Arbor on Windows 4. Performance • Concern: Does the combined environment suffer? • Solution: Deos was unmodified and maintains its certification package. Other than interrupt disable, RTEMS compiles to the same assembly instructions as on bare hardware

Paravirtualizing RTEMS • Remove protected/sensitive instructions • Replaced interrupt enable/disable with hypercalls in paravirtualized BSP • Address use of protected instructions in newlib • RTEMS now has paravirtualized support for: • x 86, Power. PC, SPARC • Deos/RTEMS available for: • x 86, Power. PC • Other architectures including ARM possible

Time Management • Partitions lack accurate global time knowledge • Need to track passage of time in RTEMS partition • Approach • Consume entire partition budget – never yield • Good design choice for real-time • Use Deos “time budget exceeded exception” to calculate time consumed outside of RTEMS • Query Deos for uptime to mark start of each RTEMS partition scheduling window • Also get uptime in clock driver for elapsed time within a window

ARINC 653 and POSIX Scheduling Major Frame Partition A Partition B Partition C Partition A Partition C Partition D ARINC 653 RTEMS POSIX RMA Threads PA 1 PA 2 PA 3 PB 1 PB 2 TC 1 TC 2 TC 3 PA 1 w 0 TC 1 PA 2 T C 3 TC 2 T C 2 PD 1 TCP PD 2 /IP w 1 • ARINC 653 Processes scheduled ARINC 653 partitions. • POSIX threads scheduled by RTEMS in POSIX partitions. • Deos kernel schedules partitions Scheduling of 653 processes or pthreads Scheduling of RMA threads Scheduling of POSIX threads Scheduling of Exception Handler

Summary • FACE Conformance requires ARINC 653 and POSIX • Deos has certified ARINC 653 support • RTEMS has robust POSIX support • Combining Deos and RTEMS leverages the strengths of both to provide a FACE Safety Base OSS solution • Future Work • Submit formal The Open Group FACE Conformance Certification • Performance tuning and design optimization

Contact Information Joel Sherrill Joel. Sherrill@oarcorp. com Gary Gilliland ggilliland@ddci. com Gedare Bloom cs. cea. howard. edu/users/gedare www. ddci. com www. rtems. com

Extra Slides

Gary Gilliland • Technical Marketing Manager at DDC-I • 25+ years experience in embedded design, avionics and RTOS • Electrical Engineering degree from University of Texas DDC-I, Inc. • Leading provider of mission/safety-critical software solutions for 30 years. • Headquarters in Phoenix, AZ • World-wide presence • Primary market: Certifiable avionics software

Joel Sherrill, Ph. D. • Director of Research and Development for OAR Corporation RTEMS Project Lead • 30 years experience with real-time operating systems including the design, development, and fielding of embedded applications in a variety of commercial, research, and military domains • BS Computer Science, University of Tennessee at Chattanooga MS Computer Science, University of Alabama in Huntsville Ph. D. Computer Science, University of Alabama in Huntsville OAR Corporation • Software and systems engineering for mission critical software solutions for almost 40 years • Headquarters in Huntsville Alabama • World-wide customer base • Primary market: Critical real-time embedded systems • Original developers and constant maintainers of RTEMS

DDC-I Core Competencies • Certifiable, safety-critical RTOS products • Deos (ARINC-653, RMA, or hybrid) • First certification in 1998 • Integrated Development Environment (IDE) • Development, testing & analysis tools • DO-178/ED-12 certification expertise • First DO-178 DAL-A (Ada) product released in 1992 • We perform our own certification work • We defend our certification artifacts during all audits • We do not reverse engineer certification artifacts

OAR Core Competencies • • • Real-Time Embedded Systems Development Operating Systems Experts Advisors, Consulting Standards Development Software Architectures & Software Engineering DEFENSE SYSTEMS - We support the entire lifecycle of today’s advanced weapon systems. Emphasis in design, development, testing, and oversight of advanced technical solutions for today’s and tomorrow military. • COMMERCIAL SYSTEMS - We provide software development and systems engineering services ranging from simple device drivers to complex applications and systems of systems.

Deos Highlights • Pedigree – Record of deployment, support & certification • >10, 000 aircraft, >10 Million flight hours, > 40 aircraft types, >100 certs • Features • Time, space & resource partitioning with ARINC 653 and/or RMA scheduling • DAL-A Linker/loader for binary modularity - Enables reuse of software & certification credits, and minimizes change impacts • TCP/IP, File system, ARINC 664/AFDX, ARINC-615 TDL, USB • Performance • Cache partitioning, low system tick overheads • Slack scheduling & time budget transfer • Multicore option • Tooling • • • Ethernet & FTP based development – with PC-based processor simulator Compiler independent (i. e. , current version) All tooling applicable through V&V (and deployment in some cases) Tooling to determine WCE for apps and target Source/Object code coverage tool provided

RTEMS Highlights • RTEMS is an Industrial Grade open source RTOS • Twenty five year history of deployment on multiple planets, unique instruments, automotive systems, and critical industrial infrastructure • Low overhead with predictable resource consumption • TCP/IP, network services, multiple file systems, USB, dynamic loading, RMA, pluggable schedulers, shell, and much more • Supports over a dozen CPU architectures • Multicore Support