DeOS

1. DeOS Mac Mollison Sept. 24, 2010

2. First, a funny story…

3. Agenda for this talk • Some new (to me) cert information • Recap of ARINC 653 • DeOS

4. Certification • RTOS re-certified as part of cert for each airplane it goes into • For example (first certs): • VxWorks => Smiths Aerospace • LynxOS => Rockwell Collins • DeOS => Honeywell • Certification artifacts sometimes supplied by OS vendor, sometimes not.

5. The Cert process • Certification performed by OS vendor or by 3rd party contractor • FAA doesn’t certify, they audit the certification • Audit consists of approx. 4 to 6 1-week reviews of documentation • Spaced with 1 week before and after for vendor to prepare and review • This info comes word-of-mouth from DeOS sales guy and is only approximate

6. ARINC 653 Recap • ARINC 653 is a spec/API for integrating software formerly hosted on separate platforms • i.e. “integrated modular avionics” (IMA) • Uses table-driven schedule to switch between partitions • Which really hurts performance and gives poor schedulability

7. ARINC 653 History • IMA idea came about in Honeywell work on Boeing 777 (‘94) • After that, Boeing pushed for ARINC 653 spec to be created and adopted by industry • Came out in ’96 • Since then, has become a strong trend

8. ARINC 653… Really necessary? • NO, it’s not. • DeOS came out in ‘95 and was (and still is) used to do multiple levels of D0-178B-certified software on one computer • Claim to use “time-space partitioning” but it uses rate-monotonic scheduling with budget enforcement and virtual memory.

9. Why use ARINC 653? • So why does ARINC 653 it still get used? • Not entirely clear to me, but… • Defines a common API, which is a strong selling point (-DeOS sales guy) • Presumably, makes cert easier • Presumably, has some soft. engineering advantages • Customers often put it into requirements • Monkey see, monkey do?

10. DeOS • “DeOS is specifically designed for safety-critical systems with mixed levels of criticality.” –their marketing materials • Looking into extending it to multicore (more on this later)

11. The rest of this talk • DeOSHistory and Delpoyment • Process/thread abstraction • Synchronization & Sharing • Scheduling • Microkernel architecture • DeOS Middleware • Multicore? • Latencies • Binary portability

12. DeOS History and Deployment • Began as a Honeywell internal project in the 1990s • Considered a competitive advantage by Honeywell • Eventually, Honeywell faced pressure to release it as COTS software • Story continues on next slide

13. DeOS History and Deployment • Licensed to embedded software house DDC-I • Who released it as COTS software in 2008 • DeOS sales guy claims DeOS IP is worth close to $100 million

14. DeOS History and Deployment • “Used in more avionics products than any other COTS RTOS” • COTS = “commercial, off the shelf” • x86, PowerPC

15. Process/Thread Abstraction • Process = set of one or more threads with shared virtual address space • Thread = executes periodically with budget allocation • All threads scheduled rate monotonically and must be harmonic • But there are some exceptions, such as interrupt handlers

16. Synchronization & Sharing • Mutexes and semaphores • “highest locker” protocol for priority inheritance to prevent priority inversions • I assume this is an implementation of PIP • Shared memory pages • “Mailboxes” with user-defined buffer depth

17. Scheduling • We already know it’s harmonic/rate monotonic • What you probably didn’t know yet is that they use some cool slack scheduling techniques

18. Slack Scheduling • If a job finishes under budget, its slack is added to the slack pool • Any thread designated as a slack consumer draws from the slack pool if it wants to run and has used up its budget • This is in addition to background scheduling

19. Slack Scheduling Example • Requirements states that monitor update must be done once every 1 second • “Customer delight” occurs when monitor update happens every 10th of a second • Not feasible to give the thread that much budget • With slack scheduling, you can achieve “customer delight” 99% of the time.

20. Time Budget Transfer • Normally, slack is doled out from slack pool in priority order • Optionally, threads can specify which other threads should receive their slack • Used to implement client-server relationships where server has no budget of its own. • Allows client/server exchanges to happen immediately within one period

21. Microkernel Architecture Applications Middleware DeOS Kernel Application Hardware CPU Platform Hardware

22. Microkernel Architecture Applications Middleware • Easy to port • Eases cert DeOS Kernel Application Hardware CPU Platform Hardware

23. Microkernel Architecture • Userspace device drivers Applications Middleware DeOS Kernel Application Hardware CPU Platform Hardware

24. Microkernel Architecture • Surprisingly large amount of stuff • is “middleware” (more later) Applications Middleware DeOS Kernel Application Hardware CPU Platform Hardware

25. Microkernel Architecture Only kernel itself runs in privileged mode Applications Middleware DeOS Kernel Application Hardware CPU Platform Hardware

26. Middleware Level E Certified Level A Certified • ANSI C Library • IEEE Math library • Sockets library • I/O interface (e.g. producers/consumers, etc.) • Possibly other things • FTP and TFTP servers (for loading software onto target) • TCP/IP stack • Status monitor • Various debugging tools • Etc.

27. Microkernel Architecture (Comparison) • Microkernel architecture is actually fairly common in the RTOS world • However, Wind River VxWorks (possibly the industry leader) is a monolithic kernel • Simple RTOSs allow everything to run in privileged mode

28. Multicore • Sales guy told me they have it running multicore but it’s not certified • Jives with what I’ve heard of DO-178B products from other vendors • They have a patent on dedicating part of the cache to one CPU and part of it to another • They plan to do mixed criticality on multicore with this • Contention for cache bus is still an issue with this

29. Latency • Sales guy says you have to sign an NDA to get latency information • Presumably, all RTOS vendors do this and that’s why we haven’t seen much latency info yet. • Claims it’s “in the tens of microseconds range” and competitors are in the “tens of tens of microseconds range” • Makes sense because ARINC 653 partitioning probably has more overhead

30. Binary Portability • Because of microkernel architecture, DeOS gives you full binary portability • ARINC 653 solutions do not have this • Since they have a common API, you can in theory just recompile • Sales guy says this is a practical problem with every time competing RTOSs are re-certified

31. Closing Thoughts • Note on DeOS ARINC 653 • Aside on Patents

32. DeOS 653? • Sales guy claims they’re making an ARINC 653 version of DeOS because customers are demanding it • Claims they have their own “twist” on it

33. Aside: Patents • Note the two totally obvious patents that are part of the DeOS IP • I’ve noticed that RTOS vendors tend to talk about/brag about their patents a lot • Maybe we should be getting patents? • If the RTOS vendors care about patents so much, it seems like Jim could sell them patents and make big $$$

34. Questions?