ARINC-653 API
Mathew Benson
mathew.benson at gmail.com
Fri Aug 3 17:28:26 UTC 2012
I'm new to both RTEMS and this mailing list. I didn't see a mailing
list search utility so I skimmed posts going back several months and
saw a thread on RTEMS and ARINC-653. I'm particularly interested in
using RTEMS for ARINC-653 applications. I'm a professional not a
student, but I fully embrace the open source movement both in my
personal projects and professional projects when possible. I
apologize if I'm resurrecting a dead thread or duplicating a thread,
but can I ask what the status of this effort is?
I'm primarily just interested in running ARINC-653 partition code
without regard to actual space and time partitioning, for now. I
already have a production environment. I have a board level emulator
that runs the unmodified binaries but its many times slower than real
time. I also have a Linux based simulated environment that satisfies
the ARINC 653 API and it is capable of running faster than real time,
but the endianness is flipped requiring an extra layer of code and
maintenance effort.
Phase 1:
My first goal is to run my existing partition code, real time, without
modifications and without byte swapping. In parallel, I'm using qemu
to do the same thing but I also want to find inexpensive big endian
boards (previous post) and run my code on those. If this were a
personal project, I would use old PowerPC Macs, SPARCs, or whatever
consumer electronics device I could find. However, since this is in
support of a professional project, I need to find something that I can
purchase and use without hacking, though I would still entertain using
discarded cell phones or network routers just for the coolness factor.
I had originally toyed with network routers, but can't find many with
the specs that I need. Once I have my platform, OS, and BSP, I plan
on writing a simple ARINC 653 (part 1 only) layer on top of whichever
OS I use (preferably RTEMS) to satisfy the APEX API, writing system
partitions for platform specific functions (i.e. I/O and board health
monitoring), and running my code. Internally, timing will be
completely out of whack, but the system partition providing I/O would
provide the appearance of at least minor frame timing coherence. Some
failure scenarios wouldn't be emulated correctly, but I'm really only
interested in nominal operation anyway.
Phase 2 (currently not planned, but possible):
Join or start a project to provide a true space/time partitioned ARINC
653 implementation of the target OS.
Phase 3 (probably wishful thinking):
Implement a DO178B certifiable ("-able", NOT "-ied") version of the target OS.
I know very little about RTEMS, but I'm more interested in using RTEMS
over Linux because it appears RTEMS was designed from the ground up
for real time embedded systems.
More information about the users
mailing list