Alex Wilson

Cost of security

Having read Paul Parkinson's blog about  the UK National CyberSecurity Strategy, it was interesting to read this article on the US government moves towards cloud computing. I have always been surprised by the seemingly complacent attitude towards security, especially with our approach of downloading daily patches and security fixes to the variety of software installed on our PCs. In the article Rob Housman agrees with this and stated "that now is the time when the government should be putting an emphasis on security and safety rather than saving money and going for the tried and true “hack and patch” approach when problems arise."

Of course, Wind River has been presenting its security technology, Wind River VxWorks MILS Platform for a few years now. In the presentation "New Capability for the Warfighter - Multilevel Secure Systems Based on a MILS Architecture" which we created with our fellow members at The Open Group Real Time & Embedded Systems Forum  we have long been evangelising the robust partitioning approach. This concept allows the system architect to divide the system into security components that are independently designed, built and tested. This approach allows for the higher security component to be tested with much more rigour at a much more reasonable cost than previous generations of monolithic computer systems.

 

If you want to learn more about the foundational capabilities of Wind River VxWorks MILS then read the High Assurance Systems Development using the MILS architecture white paper written by Paul Parkinson and Arlen Baker.

Why is security suddenly becoming such a big issue? It is because more and more of our systems are becoming connected. In the drive to provide M2M capability and connect everything to the net we sometimes forget the security implications of doing this. This is mainly because these legacy systems have been designed and built for a single purpose, not as part of a connected world. As we move systems from legacy air-gap security environments, into the "cloud" we need to update them and provide security as an additional requirement.

I know in the defence world, our customers are taking security very seriously, and that systems are being designed with more and more of a security requirement - I just hope that the current defence budget cuts around the world do not lead to reductions in these security requirements; I would hate to think that hackers could take control of some of our more advanced weapons systems and turn them on us....

Laws of Robotics

As a member of the UK Institute of Engineering and Technology, and a keen science fiction fan, it is always great fun when I see mention of advanced robotics applications in space!

This month sees the article by Piers Bizony on "Robonaut flies in". This is a great article outlining the mission on the NASA Robonaut. Robonaut was included in NASA's STS-133 payload for testing on the International Space Station.

Image Courtesy of NASA

Wind River has been working with NASA on many space missions (See Mike Deliman's Blog), and this mission is no exception. Robonaut is running VxWorks on PowerPC based embedded systems at the "heart" of its control system.

One interesting aspect of the article is the discussion of safety.  Safety, as we know, has many aspects and possible solutions. For industrial robots, anything that impacts safety is usually mitigated by shutting down the system to prevent further damage or harm. For Avionics systems involved in flight controls this of course would be a bad thing and the safety argument has to allow for continued aircraft operation after such an impact.

Robonaut in this respect has an additional challenge, it has to figure out if sensor readings mean it was supposed to interact with it's fellow astronauts or if they are a safety issue, and then act accordingly.

In actual fact, Robonaut is semi-autonomous as the article goes on to describe, with a Human operator controlling and "sensing" what Robonaut is doing - much like an Avatar - the control and feedback here is critical and hence the use of VxWorks as the trusted foundation for its control system.

There is also a really interesting side panel article on use of Robonaut for a moon landing, with the human operator on the ground, where an additional challenge is the 1s delay in signal transmission from the command and feedback signals! This mission was also covered by Business Insider with the headline "NASA Will Save $149.5 Billion Sending A Robot Instead Of A Human To The Moon
"

This reminds me of another film I saw recently with Bruce Willis, Surrogates, I wonder if this is the beginning of a new era??

 

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

Wind River VxWorks MILS is Launched!

Today we launched our VxWorks MILS 2.0 product, details can be found on our web on the VxWorks MILS Page.

VxWorks MILS 2.0 previously went into evaluation at NIAP at Common Criteria EAL 6+ and has been discussed by Paul Parkinson on his blog.

I was interested in this release as the product addresses a lot of the concerns and challenges we are facing in this difficult time. If you have been following the reports coming out of the Paris Airshow, you will have seen many signs of the economic problems facing the commercial airline industry and the hope that the defence industry carries us through to new economic growth.

One of the challenges facing the Aerospace and Defence industry along with many other industries is how to provide increased functionality to its customers, whilst at the same time preserving the safety and security of the system. A good example of this being the EADS Advanced UAV, which has a fully autonomous system for Intelligence, Surveillance, Target Acquisition and Reconnaissance (ISTAR) missions).

VxWorks MILS provides our customers with a platform that allows them to isolate and at the same time integrate this capability into a system, and then evaluate the system to the Common Criteria (and DO-178B) to prove its security.

The cost saving is immense when you consider not only the cost of the evaluation itself – the MILS seminar at The Open Group estimated the cost for evaluation of a MILS kernel to be around $5M – but also the cost of re-evaluation to incorporate technology refresh and protection from obsolescence and the impact of cyber security breaches, recently estimated at $1 trillion!

MILS technology provides a basis for layering your assurance capability in a way that allows you to evaluate the assurance of each component, starting with the trusted hardware, moving up through the Separation Kernel, adding the middleware and finally your Operating Systems and applications. This layered approach allows you to divide your high assurance code into manageable blocks which can be evaluated to the highest degree, and allow non-secure component to co-exist on the final system.

Click here to see a demo of our MILS technology in action at  MILCOM 2008.

Technorati Tags: MILS,Wind River,Paul Parkinson,Cyber Security,Cybersecurity,EADS,UAV,MILCOM,ISTAR,autonomous systems,NIAP,Common Criteria,The Open Group,VxWorks,VxWorks MILS

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 Profiles

Well, as work caught up with me I missed the Lisbon experience, but apparently it was raining there anyway - so it was just like home!

As I mentioned profiles in my last blog, I thought I would expand on these based on Andrew Josey's presentation [PDF from Open Group Site] to see what they look like and how they might apply to RTOSes (such as VxWorks), Linux and DSO in general. (He has an excellent diagram on Page 18 that shows the POSIX standards evolution....)

PSE51 or Minimal has 287 APIs and is aimed at small embedded system, with no MMU, no disk, no terminal

PSE52 or Realtime Controller has 626 APIs and is aimed at special purpose controllers, again with no MMU, but with a disk containing a simplified file system

PSE53 or Dedicated has 754 APIs and is aimed at large embedded system with file system on disk, with an MMU; software is complex and requires memory protection and network communications

PSE54 or Multi-Purpose has 912 APIs and is aimed at large real-time system with all the features,
including a development environment, network communications, file system on disk, terminal and
graphical user interfaces, etc.

Now you also find that even these are not enough and you get subsets of these such as the SCA 2.2.2 which defines a subset of PSE52 with 267 API calls. This API is also most likely to be one used in Safety Critical Systems as the SCA is required for this under JTRS.

So, the theory goes you would pick the correct subset based on the type of application you are building. And in fact I think the theory works well; say you build a small standalone system dedicated to single function using PSE 52, then as systems merge and performance increases you want to merge that onto a larger system the application can be "easily" ported to a PSE 54 system.

Of course, the question still remains as to whether the PSE 54 system has the Real Time capabilities you need to execute your code correctly,  and that the PSE 54 system you port to is as conformant as your PSE 52 system, but that's what the conformance tests Andrew Josey presents are all about, right?