|
for Do178Builder |
|
|
| This
page is provided for historical interest (if any) only. The
projects and roadmap described have proven to be unqualfiable. |
First steps: A fictitious project, "libBirds" A short essay: The classic problem with DO-178B A Roadmap for an airborne runtime environment
In order to demonstrate the use of Do178Builder, I've provided a sample project called "libBirds". It was created at a time when I expected to personally provide source code for it, and hence is designed for maximal implementation simplicity. These expectations have changed, and I won't proceed with libBirds development. Hopefully, a more complete Do178Builder project will eventually appear as newlib-1.9.0.Even though the libBirds library has no code, and hasn't been developed very far, it can at least show you what Do178Builder does, and how it does it.
The libBirds project is unlike most airborne-software projects, in that it is not a complete piece of airborne firmware itself, but is rather a general-purpose software library intended to be pre-qualified for later use in other airborne-software projects. In other words, by isolating certain common software elements from various projects, the certification effort for the common elements needs to be applied just once, rather than being applied over and over again for each project. This odd characteristic of libBirds is neither desirable nor undesirable for the purpose of demonstrating Do178Builder, so don't come to the incorrect solution that Do178Builder works only for reusable software libraries.Note that when I wrote the libBirds sample project, I was unaware of soon-to-be-released FAA guidance on Reusable Software Components (RSC), notice 8110.97. If libBirds was an actual project rather than a sample, it would need to be modified in accordance with N8110.97. But since libBirds is just a demo of Do178Builder, I haven't bothered with it.
Because the use of Do178Builder is being illustrated, the materials provided here are Do178Builder XML project files. Do178Builder has several strengths that make the DO-178B based software development effort easier, but one important strength is that project data can be created in appropriate stages. In other words, initially you only provide the bare minimum of data needed to initiate the project. Later, additional data is added, or less-detailed data is fleshed-out in greater detail, as the project proceeds to later development stages.So we illustrate this by giving you a series of snapshots of the XML data, appropriate to the various development stages. The development stages for the libBirds project are outlined in the Plan for Software Aspects of Certification (PSAC) document. Actually reading the PSAC will fill in all of the details for you. Of course, since no actual libBirds software exists, certain parts of the documentation will simply never be filled in. For example, the "SQA Manager" will be listed as "TBD", and there won't be any SVR (software verification results).
Images (such as graphical figures) are also provided, since they are separate from the XML project files, and not somehow embedded within them.
| Milestone | XML &
images |
DO-178B Deliverable Documents |
|---|---|---|
| Draft PSAC | libBirds-xml-draft.tar.gz | PSAC. |
(This, folks, is the "personal opinion" part of my presentation.)Unlike the libBirds sample project, a fully fleshed-out sample project that included code would actually be deployable (i.e., certifiable) for airborne use. There's a crying need for this, because proprietary airborne software has some practical problems.
A classic problem of airborne software, in my view, is that certification requirements ironically often act to force the adoption of inferior software. The reason for this is that high-quality off-the-shelf software is never available certified for airborne use (at least, at a finite cost attractive to smaller developers). Commercial software is seldom even theoretically certifiable above Level E, because source code is usually not available. Open-source software is theoretically certifiable, but in practical terms may be uncertifiable by virtue of the sheer quantity of source code. Also, even if a given developer managed to certify (say) Linux, he would not share any of the documentation with any other developer, and so the huge amount of certification work would have to be done over and over by different developers. For these reasons, developers almost always reinvent the wheel and recreate in a scaled-down form software functionality already available elsewhere in mature form. One can only suppose that these do-it-yourself efforts are sometimes not of as high quality as already-existing software created by experts in the relevant fields.
Consider my own work, for example. One type of product that I've created several versions of is an audio checklist system for the pilot and copilot. Now, this is a reasonably small application, of limited use, and I'm reasonably happy supposing that my audio-checklist application code (given design contraints placed on me by Marketing and Management and so on) is probably about as good as can be expected. No problem; DO-178B has done its job, right?
But wait! That audio checklist application has to run atop some operating system, right? So, I roll my own operating system, and the code for the operating system is bigger and more complex than my audio checklist application. And, I'm no specialist in operating systems. It works, certainly, but is it as good as the code from someone who actually specializes in operating systems? No, I fear that it is not.
But there's more. There has to be a file-system, too. So I roll my own file-system. And the code for the file-system is bigger and more complex than the code for the operating system. And am I a specialist in file-systems? Of course not; I just make it all up as I go along. It works, and it works well ... maybe.
And let's not forget communication protocols. Say that I have several units which must intercommunicate, and so I have to invent and implement communication protocols ... well, let's not get into that. It's more of the same, and I presume that you see my point.
One often sees enthusiastic statements in operating system manufacturers' literature of the form "our operating system is really, Really, REALLY reliable, and therefore is suitable for medical applications, aviation applications, etc., etc., etc." From a naive point of view this is very reasonable, but it betrays an absolute ignorance of the reality of airborne software -- at least, from the smaller developer's point of view. The reality is that the reliability of the operating system is irrelevant if the operating-system software is uncertifiable, since if uncertifiable the software cannot be used. For airborne purposes, inferior certifiable software must be regarded as preferable to superior uncertifiable software.
The whole setup smacks of the Wizard of Oz's assurance that the Scarecrow didn't need a brain as long as he had a diploma.
The key, as an industry, to providing plentiful, reliable, low-cost airborne software is to have a certifiable, preferably free, operating systems and libraries atop which developers can run their application code. In other words, to allow developers to concentrate on developing and certifying their applications rather than their runtime environments. The most efficient way to go about this would seem to be finding high-quality open-source software which may be certifiable for airborne use if only somebody applied the effort to do so. In attempting to certify software that already exists, and which was written without certification in mind, the problem is complexity. The bigger the code, and the harder to understand, the less likely that it can be certified. My own additional requirements are that the code be very portable, and that it be free software preferably licensed under the GPL. Certainly, Linux and BSD are out of reach on the basis of their complexity. Some other operating-system possibilities are: RTEMS, Red Hat eCOS, and RoadRunner.
In connection with my work, I have explored some of the commercial options for airborne operating-system software. A number of commercially-available operating systems claim to be suitable for airborne use, if one believes everything one reads on company websites and conversations with sales people, but in general I have had very little luck in getting satisfactory information about such usage. The uC/OS website mentions an "FAA validation suite" which indeed appears to be impressive from the sample documents provided. Of course, few commercial choices are free software, though some are more cost-effective than others. I've seen claims of airborne usage of RTEMS, but only in devices that seem to be at software Level E (hence requiring no certification effort).
Here's what I envisage:How to get there from here? Here's a plan:
- An open-source runtime environment suitable for airborne use at software Levels C, D, and E, licensed for free use under open-source licensing, extremely portable across different processor and system architectures.
- DO-178B documentation for this free runtime environment, also available for free with licensing under an open-source license.
- Free C-based development environment for the airborne applications used with the runtime environment.
- Well, I visualize using the Do178Builder tool to manage the projects and the documentation. That should come as no surprise.
- The free C-based development environment would be the GNU gcc toolset. This is a no-brainer decision, and doesn't actually require any certification effort as such.
- Certification of Red Hat newlib version 1.9.0 (or possibly some subset thereof), an embeddable replacement for the standard C library.
- Certification of some open-source RTOS.
newlib-1.9.0 Documents Milestone XML &
imagesDO-178B Deliverable Documents Draft PSAC newlib-Do178Builder-20020225.tar.gz PSAC.