Alex Wilson

Airbus A400M and Boeing 787 Dreamliner first flight

Wow!

What a week for our customers in Europe and USA! Last week saw the first flight of the Airbus A400M Military Transport and today the Boeing 787 Dreamliner took to the skies!

Congratulations go out to Airbus, Boeing and all of their worldwide suppliers!

Our man on the ground at Paine Field, Everett is Chip Downing, Director of A&D Business Development and he managed to send us this excellent video of the event!

It will be interesting to follow these two aircraft as they go through their respective flight testing and enter service!

On the Avionics side, the 787 Dreamliner is the result of collaboration between Boeing and its suppliers to integrate multiple applications at different safety levels on the Common Core System. This strategy of avionics development follows the RTCA DO-297 role based development concept, allowing each application developer to work independently of each other and provide the necessary safeguards for the systems integrator to bring this all together in the final configuration for this historic first flight.

The independence of each application is fundamental to allowing them to be designed, developed , and tested in isolation. DO-297 provides guidelines for each role in building the safety case for the aircraft, and by having these independent “components” the applications can be tested in isolation before being tested as part of the final system. This save a considerable amount of time and effort in software testing terms and provides a solid foundation for the final system integration tests.

As part of the work to develop the 787 Dreamliner, Wind River worked with the team to expand and develop the ARINC 653 XML schema. The schema was originally provided as an example of how you might use XML for ARINC 653 systems configuration, but had a lot of missing links and cross-referenced information that made it all but impossible to use on a large scale systems such as the 787. The modified XML schema is now being adopted as part of Supplement 3 to ARINC 653 Part 1, in order for the benefits it provides to be shared in the Avionics community on future projects – this is what open standards are all about!

The backbone of the Common Core System is Wind River’s VxWorks 653 Platform. This includes the VxWorks 653 RTOS provides the fundamental components needed to build such a system based on the ARINC 653 standard. Wind River launched the safety critical version of VxWorks in 1999 for federated avionics, and followed on with VxWorks 653 in 2003 for Integrated Modular Avionics. As a COTS Software supplier to many industries, we wanted to develop the DO-178B Level A certification evidence for VxWorks 653 as a COTS solution, so that our customers could benefit from not having to re-certify the OS every time it was used. We came up with a unique hyperlinked DVD with our partners Verocel that allows customers to have a copy of all the safety related material in a fully traceable format that helps them to build the systems safety case. Included in this material are not only all of the safety related documents that need to be provided to the authority (such as PSAC, SAS etc) but also the software development folded, including all VxWorks 653 source code, test code and test coverage results.

Previous Press Releases from Wind River for these aircraft include:

2004 : Smiths Aerospace Selects Wind River for Use in Boeing 7E7 Common Core System

2006 : Wind River to Support Development of Military Communications Device by EADS CASA for Airbus A400M and MRTT Tanker

2006 : Wind River Platform for Safety Critical Devices To Power Indra Sistemas Aircraft Identification Project for A400M Military Aircraft

2006 : Innovative Design and Safety-Critical Software Enable Refuelling Wing Pod

Avionics 09

I am back in the office after a busy few weeks at Embedded World and Avionics 09. I read in the news that the third C-130AMP has its first flight ahead of schedule which is excellent news in these days of doom and gloom over the economy!

The C-130 AMP is a heavy user of our technology, so that prompted me to go ahead and write about Avionics 09. Wind River had a very busy show, with a conference paper, 3 workshops and a master class, which kept us all busy for the two days!

We showcased the EADS DMG-S for the A400M on our stand, which is a great example of moving map application running on VxWorks 653 with ALT OpenGL graphics engine.

Chip Downing gave a great paper on MILS technology during the main conference. I was privileged to chair one of the main conference sessions, introducing Rockwell Collins to talk about HGS, HUD and other displays, and George Romanski of Verocel who gave an update of the work going on for the DO-178C standard - something we are all looking forwards to!

The conference gave some excellent papers and update on various Avionics projects, unfortunately I missed some of the session to give a workshop and Master class. I did catch the keynote by the FAA who covered Future Air Traffic Management (including NexGen), taking us on a "flight" from flightplanning through to the final taxi to the terminal - a fascinating look at infrastructure and avionics for the future ATC system.

This was aligned and expanded by Eurocontrol who did the same for the EU project SESAR, but who expanded this to show how it will align with Military air users and technology. It is good to see these two projects are in alignment, especially as I travel between them quite frequently!

I presented Larry Kinnan's paper on the issues of multicore and certification, which I think was well received - if any one wants a copy of the paper please feel free to email me.

Olivier Charrier presented an overview of IMA certification with George Romanski of Verocel, and also presented a paper with Michael Fries of AdaCore.

We gave a Master Class of developing high performance graphics with Presagis, GE Fanuc and Seaweed, demonstrating the solution running at 60Hz with VAPS XT, VxWorks, GE Fanuc Magic 1 Embedded Computer and Seaweed's Open GL Stack.

All in all I had a very busy show, with customer meetings and presentations, I don't think I had time to walk around the event to see what other stands were showing!

Did you attend the show and what did you think?

More Eclipse news

Following on from my last blog, I see that  RTI has also joined the Eclipse Framework.

This bring to the Eclipse life cycle model RTI's excellent tool for looking at distributed systems using RTI's DDS through Eclipse Perspectives. You can read more about DDS at RTI's web site

This means you now have the capability in Eclipse to move from UML all the way through coding and testing, to OS deployment and now middleware with distributed systems - What a  cool environment!

With each new tool added to Eclipse it becomes more and more powerful for developer's and in particular for developers of device software.

Personally, I think it is good to see these tools coming together in such a seamless way.

What do you think?

Tools standardisation

Changing tracks for a moment I couldn't help but pick up on one of my Google Alerts this morning regarding what is essentially the technology behind DSO standardisation - ECLIPSE.

Here is what I read

Pluginfest Day TwoBy Adrian Taylor

Some of the tools available from WindRiver, for example, are just light years ahead of what’s available for Symbian OS. ... The QNX and WindRiver tools are terrific. WindRiver’s memory profiling stuff in particular blew me away. ...

www.macrobug.com - http://www.macrobug.com/blog

Now, as one of the DSO tenets is that of software standardisation and in particular the alignment of tools across the project life cycle, I couldn't resist taking a look at this. This has traditionally been difficult in the A&D industry due to the complexity and diversity of end user systems.

But as the ECLIPSE project really matures we can start to see the benefits of this standardisation from the software development side.

Take a look at the great screen shots of products working together here, I particularly wanted to point out the shots of Workbench with Perforce, Rhapsody, Klocwork and IBM (RSD and TestRT), (scroll down past the Symbian stuff to see this...)

I think this is great news for our industry and will benefit us all by bringing together a comprehensive software development framework across the entire life cycle to allow us to get on with developing device software applications rather than figuring out how the tools can be made (or forced) to work together!

Software Certification

I wonder why it is always the case that the period of time just before year end is suddenly very hectic! There must be a universal law about that, something like Murphy's Law...

Anyway, I have just returned from 2 weeks of travel around Italy, Sweden and the US visiting customers and presenting our solutions. I always enjoy meeting folks and seeing what they can do with our software as I love to see the latest and greatest devices; and so I have been negligent in posting to my blog for that time and noticed over the last few weeks some noticeable events have taken place.

Firstly we had the final certification of the Airbus A380, a long awaited event, especially after the reported delays [See blogs by John Bruggerman and Paul Parkinson] . I noticed an interesting point in the press release on this. Namely that the certification had begun with system tests in 2001. This shows you the amount of time and effort it takes to take a complex aircraft such as the A380 through certification.  I was amused by the lack of software mentioned in the press release, I guess most readers don't want to  hear the aircraft is flown by software these days?

Secondly, we had the first flight of the long awaited F-35 Lightning II. The UK government has also finally signed up to the next phase of the project which means we can expect to see some UK business for F-35 over the next few years. It is kind of interesting seeing these arguments over technology transfers in a company who has embraced Open Source in a big way!

Both of these aircraft are using RTCA DO-178B for software certification, so I think I'll take a look at that standard. I wonder if the UK F-35 will be accepted with DO-178B or will they need our own DEF STAN 00-56?

Which brings me to the point of my blog, which is why are there so many software safety standards out there? It seems that this area of software development that does need to consider a little standardising of it's own, or even using a standard of standards (I guess you can do that if (as Paul Tingey discusses) you can have a "consortia of consortia"?)

It seems each time a new aircraft (certainly military), or unusual project begins, committees form and new standards for software safety emerge, even though the FAA and RTCA have been using DO-178B for a number of years, and very successfully too.

Some of the customers I met with do have another issue on this; that is they are creating devices that could put lives at risk in systems that do not have an applicable safety authority, such as land vehicles or submersibles (which reminds me - I must find out if the road safety authorities look at software safety).

The time spent on creating these "new" safety standards would be better spent utilising what already exists - if all of these efforts had been used to enhance best practices around the use of DO-178B wouldn't that make the device software world a whole lot safer? After all isn't that one of the key tenets of DSO?

BARCO's MOSArt

Another great piece of news!

I was really pleased to see the announcement on BARCO's use of our VxWorks 653 operating system in their MOSArt system.

I remember many years ago when BARCO decided to embark on the MOSArt project and they chose  Green Hills over us, if I recall correctly because at the time we had only just started our ARINC653 product line. Now they have come back to us to build a state-of-the-art environment based on our technology.

We originally developed VxWorks 653 to address the technical requirements of the  C-130AMP programme, which is now flying ,  and this is now also being used in demanding environments on the Airbus A330MRTT and Boeing 787 . It's been a privilege seeing Wind River participate in the ARINC 653 working group and contribute to the evolution in this standard, and this ensures that as the standard 'evolves', so does our product.

I was lucky enough to be at Avionics 06 earlier in the year and got to see a demo of the MOSArt software at work, along with some pretty cool digital mapping software! This must make life easier for pilots and navigators.

I also think this is another great example of DSO and the use of open standards. An application developed that used the ARINC 653 API would just be able to move between ARINC 653 OSes - which is one thing you want from an open standard - portability.

Great news for POSIX

If you didn't see the Press announcement, we have just completed our conformance testing of VxWorks to POSIX 1003.13 PSE52 with The Open Group  [IEEE Conformance Web]!!

This adds to the long line of "firsts" for VxWorks, including my favourite of being the first RTOS on MARS!.

As I outlined in my blog on POSIX Profiles then PSE52 or Realtime Controller has 626 APIs and is aimed at small embedded system, with no MMU, and with a disk containing a simplified file system. In addition remember that SCA 2.2.2 (for JTRS) is a subset of this profile.

This is great news for all DSO developers who need a fast, deterministic Real Time Kernel with POSIX support!

Congratulations to the VxWorks Engineering team for this excellent news!

Obsolescence and Standardisation

I was reading through one of my (many) news feeds the other day when I came across an excellent article in Flight which reminded me of issues around obsolescence. The contract as for an upgrade to the RAF Spitfires for modifications to the landing gear to accommodate new tubeless tyres.

This reminded me of a presentation given at the COG in Scotland a few years back with the example of the B52, which now has an estimated life-cycle of around 94 years! Both of these examples show systems whose life expectancy has been extended and are now having to cope with "new technologies"

At the time I was presenting Software Obsolescence and looking at techniques such as technology insertion, and mid-life upgrades. However, they key to these is of course open standards so that you can migrate application level software easily and efficiently to the new "platform"

Software Obsolescence is in some ways more complex than hardware, because in hardware (of course I am over simplifying here...) you have skilled engineers who can build components for legacy systems from scratch. But can you imagine in 90 years time someone being able to find (or build) a PC that can run Windows 2000, and then load some software tools to be able to maintain some Device Software targeting a PowerPC 750?

In some way what we need is for the standards to merge and become interoperable, both on the hosts systems and in the DSO world. Paul Tingey just wrote an interesting article on the "open Standards" debate which looks at some of these issues, and you wonder if standards such as POSIX and ARINC 653 must at some stage converge?

Compliance vs Conformance?

What is the difference between compliance and conformance and what does that mean to you and me? Or more importantly what does this mean to your project?

Well, compliance is an informal industry term generally accepted to mean the system provides support for some of a given standard. Technically, an OS that provides only one API of a POSIX standard is "compliant," though not very useful. Vendors of compliant systems are generally expected to offer documentation describing which parts of the standard are supported, and which are not. Wind River for instance, has such a statement to show "compliance" levels of its VxWorks Operating System against the various POSIX standards. This reads like 100% conformance to SCA 2.2.1 (another POSIX Subset for Software Defined Radio) etc.

Conformance on the other hand is a recognition of  formal testing, that prove that an operating system provides 100% support for a given standard. Certification of conformance is awarded to an operating system after an official Certification Authority has reviewed not only the results of formal testing, but formal conformance documentation as well. In the case of POSIX this is well covered on the IEEE and The Open Group sites. Products that are POSIX certified can claim conformance, and in doing so also publish a list of which of the optional components they support to exactly define what support they provide. This statement also lists the configuration of the system, and the test environment required to re-produce the tests.

To do this the company involved must purchase an official test suite  from a certification authority , run the tests and  submit the results for certification for conformance. As of November 2003, The IEEE and The Open Group extended POSIX Certification to the 2003 Edition of IEEE Std 1003.1. This has subsequently been extended to include IEEE Std 1003.13-2003 (what we are interested in),  for  both  the PSE54 Multipurpose Profile and  the  PSE52 Real time Controller Profile. The test results are supplied to the Certification Authority  such as the IEEE or The Open Group, in order to audit the results and confirm they have all passed. This along with the Conformance report then give a company the right to say they are conformant to the standard tested against.

Certified conformance is obviously a much better indication as to a product ' s suitability, if POSIX is a requirement for your system, as you don't have to rely on marketing data sheets showing "compliance" but know the product has been audited and tested to the standard involved. You as an application builder can then tick the box and get on with developing a product just using the chosen standard.

As John Jones pointed out on my last blog only one company is listed as having run these tests and that for 1003.1, the complete POSIX standard, this in itself is interesting as the older POSIX standard 1003.1-1998 had many companies listed against it (from memory as I could not find the old listing anymore!

I wonder why this is? 

One reason for the lack of testing at the Real Time OS level is that the PSE52 and PSE54 tests are  relatively new, not only to the POSIX community, but also to the DSO world and you have to adapt these tests to run in a DSO environment (such as porting the test suite from a UNIX based self-hosted environment to run in a client-server mode, as a device target doesn't always have the system resources to support running the large test framework)

Another reason could be the usual product development issue of scheduling in these additional workloads into an already heavily oversubscribed feature development schedule along with demands for more "exiting" technologies such as Mobile-IP  [Webopedia] or Remote Diagnostics [Wind River Management Suite].

Or maybe the demand to see these POSIX certified products just is not there yet?

POSIX and DSO

Next week I am off to the Open Group Meeting in Lisbon (excellent!) to talk about High Assurance Software and MILS [podcast link]. No doubt POSIX will come up as the OpenGroup "looks after" POSIX.

If you did not see the comment on POSIX posted to my last blog take a look. This is POSIX in a nutshell - it was originally developed as a way to "unify" all of those UNIX [www.unix.org] Systems out there (BSD, AT&T, Solaris etc..) by creating a common API for application portability. At the time (if I recall...) they were looking to compete for the desktop against the upcoming WIN32 API...No need to ask which strategy worked here...

(I did not even include Linux [www.unix.org] here - which is NOT POSIX - although very similar....and probably for another Blog)

Since then, however, POSIX has been adapted to force this high-end desktop API into our DSO world, with extensions and profiles aimed at defining an API subset for "embedded" and or "real-time" devices. The portability is also not guaranteed as their are many "optional" components that vendors may or may not implement....I will discuss profiles further next week....

As well as this the "Profile" concept works as long as you pick the right "profile" for the right application - you would not want to use a multi-user profile for an ejector seat control now - or would you??