Paul Parkinson

Rhapsody && Coverage Analysis

I've recently been working with a customer to integrate Wind River Coverage Analysis (formerly known as CoverageScope) with Telelogic Rhapsody within their development tools framework for a mission-critical system.

At first glance, it might seem strange to integrate a code coverage testing tool with a UML design tool, as these aren't even adjacent phases in the software development life cycle (implementation being between them). However, the advent of Eclipse in recent years has helped to break down the silos which used to confine tools individual development life cycle stages and improved development work flow.

The integration enables an application to autocode-generated from Rhapsody and built with Coverage Analysis instrumentation and downloaded and run on the target processor, with coverage results being continuously streamed back to the host and displayed in the Coverage Analysis GUI. This provides immediate feedback of of the level of coverage, and the coverage trend against time (useful for confirming if the test suite tests more and more code over time, or whether it is testing the same code over and over again).

The aspect of the integration which left the biggest impression on me though, was how it enabled the customer to confirm that the right code is executed in response to an event being injected at the UML model level. This is an important aspect of system testing, and it is often difficult to demonstrate the traceability from design to implementation. This was achieved by building the application with both Rhapsody animation and Coverage Analysis instrumentation, and then run or animated on VxWorks with events being injected from Rhapsody and the executed code was shown in Coverage Analysis.

If you're interested in seeing this for yourself, the integration steps are now documented in AppNote-344 on Wind River Online Support website (login required).

Drive by Ethernet?

I read last week that BMW has been researching the use of the Internet Protocol (IP) over standard Ethernet (Cisco) to network automotive controllers ('BMW brings Internet protocol under the hood', EETimes).

The motivation for the research is that at present, a number of different networking technologies (including CAN, LIN, MOST and FlexRay) are used in automotive applications, and these are optimized for different types of application, but the lack of standardization results in complexity and cost.

So, I was expecting the article to say that BMW had found Ethernet to be suitable for non-critical applications, but not well-suited to critical systems. Sure enough, the article mentioned that the network had included a multimedia server and a camera (presumably for assisting reversing rather than videophone calls), but I was surprised that the BMW research group had found that:

'IP could well suit the real-time requirements even of safety-critical applications...Our experiments with prototypes demonstrated, that the real-time behaviour far exceeded the requirements — even when we ran multimedia applications across the same network'

Why was I surprised? Well, Ethernet, following its invention at Xerox PARC in the early '70s has become extremely widely used due to an ongoing favourable performance to price ratio, but it does suffer from latency and determinism problems to a certain extent, and while this has been acceptable for many uses including even some A&D mission-critical systems, safety-critical systems which require predictable latency and guaranteed delivery have often used profiled Ethernet implementations (such as ARINC 664) instead, sometimes with the additional expense of AFDX dual-redundant networking.

So, the BMW research engineers must have found away around the automotive problem? According to the article, they used Quality of Service (QOS) and traffic-shaping (wikipedia) techniques to achieve the real-time performance requirement, but unfortunately it doesn't go into details. I'm curious to know if the network profiling requirements for automotive applications have any similarities with avionics networks, or if there are major differences in terms of latencies and traffic characteristics. Maybe there's scope for more technology transfer between the two sectors (as I mentioned in my previous blog)?

There is potentially another interesting parallel between automotive and A&D - the use of multiple networks. In aircraft, multiple on-board networks are used for avionics systems, crew information systems and passenger infotainment systems, separated by firewalls for reasons of safety and security. (This also has the added benefit of reducing the safety certification burden of systems because they are not connected to the avionics network). In a car, I would expect that the automotive control systems would be on a separate network from the infotainment systems (for safety and security reasons).

According to the EETimes article, BMW doesn't have any current plans to put this technology into a production model yet, new technologies often appear in manufacturer's new high-end models, and then the technologies tend to trickle down to other model ranges.

So, unfortunately I might have to wait a while to do a back-to-back test of Ethernet-driven and conventional versions of BMW's awesome new V8-powered M3 to compare the latencies of the Dynamic Stability Control (DSC)...

A robot in every home

I've been trying to keep track of industry news, and at the moment it seems as to me as if everyone is either blogging about the Apple iPhone  (Engadget blog) or Windows Vista (Windows Vista Team blog). However, the announcement that caught my attention recently was the launch of the 'Microsoft Robotics Studio' (IET).

The story briefly mentions Microsoft's plan to "establish standards for controlling robots", but didn't go into technical details, although I managed to find some useful background in Bill Gates' article  'A robot in every home' (Scientific American).

The article makes a promising start by mentioning common standards and platforms, and I was starting to wonder if Microsoft might actually be beginning to embrace  Device Software Optimisation (Linux Devices);  but after reading a little further, I found that the instead of enabling choice and flexibility for hardware platforms, the Microsoft Robotics Studio appears to be tied to the PC architecture (the phrase "We may be on the verge of a new era, when the PC will get up off the desktop..." seems quite revealing). The article also mentions open platforms, but I couldn't find any mention of open standards to enable vendor choice and interoperability, only Microsoft-proprietary software. In fact, a report in The Register seemed to express dismay that the statement by Microsoft "...there is a sense of openness..someone with a Mac could fire up a web browser an interact with a robot from there" - this really only appears to pay lip service to open standards. So, it doesn't appear that Microsoft is adopting DSO yet.

However, Scientific American article is quite thought provoking in other ways. Bill Gates mentions some of the functions performed by contemporary robots: including vacuuming the floor - probably referring to the Dyson DC06 vacuum cleaner (PDF: IPI Industrial Robots, Article 2); but strangely he doesn't mention the incredible engineering achievements of the Honda ASIMO humanoid robot (wikipedia), or the Mars Rovers which are being taught new tricks (BBC News) and have an increased level of autonomy. He then goes on to mention some potential robotic applications in the future, including treating patients and handling hazardous materials. Although the word safety isn't used once in the entire article, these are definitely are safety-critical applications, and made me wonder if Microsoft is finally planning to enter the safety-critical software market? This would certainly mark a significant change in direction.

So, will Microsoft take the bold step to truly embrace COTS open standards and safety-critical systems, or will it continue down the closed proprietary route?

Safety Standards Convergence?

In a recent post on software certification, Alex Wilson asked why there are so many software safety certification standards? The current situation is of course due to historical reasons, and this has resulted in some interesting anomalies. However, I think there is some reason for cautious optimism, as there appears to be more increasingly widespread acceptance of standards in recent years, and there is also a degree of convergence between standards, at least in some cases.

The RTCA DO-178B standard was originally developed for the safety critical software on civil aircraft certified by the US FAA, but in recent years this has been increasingly adopted by US military aircraft programmes, and subsequently on civil programmes in other countries around the world. (In Europe, civil aircraft are actually developed according to the EUROCAE ED-12B standard, but this is identical to DO-178B).

In the UK, safety-critical defence systems have been developed for many years according to Defence Standard 00-56 Issue 2. In my view, this standard places a strong emphasis on safety through correctness of design, and less on process when compared to DO-178B. So, this would seem to make it difficult to develop safety certification evidence which is relevant to both Def Stan 00-56 and DO-178B. However, the more recent Interim Defence Standard 00-56 Issue 3 (Part 1 PDF, Part 2 PDF) which is actually very readable, takes a markedly different approach to Issue 2, being rather less prescriptive, whilst providing a framework within which contractors may use a suitable process and methodology for their programme. In theory, this could make it possible to use certification evidence which has been developed on according to another software safety standard to be used under Def Stan 00-56.

The Interim Defence Standard 00-56 Issue 3 is now being applied to UK defence programmes, but I don't believe it is being applied retrospectively to programmes such as the UK F-35 Lightning II. So, returning to Alex's question: 'I wonder if the UK F-35 will be accepted with DO-178B or will they need our own DEF STAN 00-56?' I expect that this will be delivered with certification evidence to DO-178B. However, I do wonder if this will cause operational issues, as has been the case with other aircraft which have been safety certified under DO-178B which are in service with UK forces?  This certainly has proved to be a problem for the UK RAF with their Chinook helicopters (see the BBC News stories 'Chinook Blunder Left RAF Short', and in particular 'Chinook helicopters up for sale?', which includes a very pertinent statement:

"The blunders involved, which sound almost farcical, have resulted in the purchase of machines that may well be perfectly safe, but have so far proved impossible to certify."

This is referring to the fact that the avionics and navigation systems were been developed under DO-178B, but not to a sufficiently high equivalent Software Integrity Level (SIL) under Def Stan 00-56 for UK deployment. The outcome of this has been unsatisfactory, as the RAF Chinooks are not permitted to fly in poor visibility conditions (night, fog, etc.).

In his blog, Alex also asked if there was convergence between avionics and automotive safety standards, but I think that probably deserves a blog in its own right.

VxWorks 6.4 POSIX PSE52 Conformance Certification

In the post 'Great News for POSIX', Alex Wilson commented on the announcement that VxWorks has becomes the first operating system to achieve certified conformance to POSIX PSE52 Realtime Controller 1003.13 standard. Alex has also discussed the different POSIX profiles here.

I was thinking about what this announcement means for developers? I have to confess that it's been a while since I spent all my time writing code, but I can clearly remember when I used to write device drivers and interface libraries under SunOS, Solaris, OS-9, LynxOS and VxWorks (wikipedia) to interface enterprise UNIX platforms and RTOS platforms to high-performance digital signal processor (DSP) VME boards.

The internals of each OS were of course quite different, which had an impact on the design of the device drivers, especially where multithreading (wikipedia) and MT-safety were concerned. The implementation of MT support provided by the OS platforms varied to a certain extent, so careful design was required to achieve a consistent application library API across platforms to aid portability and to ensure that the implementations behaved in a consistent manner too.

The most logical way of doing this was to use POSIX, as this was often at least partially supported on each of the OS platforms. (The Solaris implementation of threads had some differences, but this was well covered by Bil Lewis and Daniel J. Berg in 'Threads Primer - A Guide to Multithreaded Programming' (p117, according to the edition which is still on my bookshelf). By using an abstraction layer, it was possible to avoid exposing any OS dependencies to the user in the application libraries API.

Back to the present, now that VxWorks 6.4 has achieved 100% PSE 52 conformance, I can see how this will make it easier to implement portable libraries (and applications for that matter) on different real-time platforms. In A&D, I can imagine that this will be useful for programmes undergoing mid-life update, who want to migrate off legacy platforms; and for new programmes, who want to develop portable code to enable future portability.

Mapping Out The Future with TARDIS

I've just read a interesting article - 'Mapping Out The Future With TARDIS' in the journal Jane's International Defence Review (Volume 39, November 2006, page 29 Upgrade Update). Despite the title, this isn't about The Tardis (wikipedia) time machine featured in the Doctor Who sci-fi television programme; but instead the Tornado Advanced Radar Display Information System developed by BAE Systems for the UK Royal Air Force's Tornado GR-4 ground attack aircraft.

The Jane's IDR article discusses the Device Software Optimisation (DSO) strategy adopted by BAE Systems, and a high-level overview of TARDIS' capabilities. TARDIS actually uses state-of-the-art active matrix liquid crystal displays can be used by the Tornado pilot and navigator either co-operatively or independently, and perform data fusion of radar data and digital moving map display data to provide advanced enhanced situational awareness for low-level terrain navigation and avoidance capabilities.

TARDIS performs data fusion and display by using a high-performance multiprocessor architecture, with interprocessor communication via VMEbus backplane. Monitoring communications between multiple processors in a real-time system can be challenging, especially when using an intrusive development tool such as a debugger which can affect the real-time timings, but BAE Systems' engineers were able to use the Wind River System Viewer during the system integration to observe the real-time performance of the TARDIS subsystems. You can read about this in more detail in the case study (PDF) on the A&D Customers page.

So, to a certain extent TARDIS does behave as a time machine, enabling the RAF pilot to navigate forwards in time and space..but not backwards in time as this would violate the Hawking Chronology Protection Conjecture (wikipedia).

The Ravenscar Profile

A few weeks ago, I took a few days leave to enjoy the end of the British summer and went hiking amongst the green hills and valleys of the North Yorkshire Moors. What's that got to do with Aerospace & Defence or device software? Well, apart from the early-warning radar at the RAF Fylingdales base (wikipedia), you might think not very much. But on the coast just a few miles south of the fishing village of Robin Hood's Bay lies Ravenscar, which is now a familiar name in the field of the development of high-integrity and hard real-time systems. (Here's a photo that I took from the Cleveland Way path which shows the profile of the coast at Ravenscar).

In 1997, at the 8th International Real-Time Ada Workshop, a subset of the Ada programming language was defined for safety-critical real-time systems. This has come to be known as the Ravenscar Profile, and was published as:

A. Burns, B. Dobbing, and G. Romanski. 'The Ravenscar tasking profile for high integrity real-time programs '. Reliable Software Technologies, Proceedings of the Ada Europe, Conference, Uppsala, pages 263–275. Springer Verlag, 1998.

Alan Burns has also created a good summary of the subsequent evolution of the Ravenscar specification, which is available from the University of Madrid website (PDF). In recent years, the Ravenscar Profile has gained widespread acceptance and was incorporated into the Ada 2005 standard. For a very good overview of Ada2005 and Ravenscar, it's worth checking out the article  "Ada 2005 Strengthens Ada’s Safety-Critical Muscles" by Robert Dewar, CEO of AdaCore which was published in COTS Journal online. (If you would rather watch a video, there's a talk on Ada 2005 for high-integrity real-time systems by Jose Ruiz on the AdaCore website).

The Ravenscar Profile's support for concurrency has had an important impact on the development of high-integrity systems; so has the inherent support of schedulability analysis which is needed in order to determine if essential deadlines will be met in hard real-time systems.

Ravenscar has also had another important impact in the implementation of safety-critical real-time systems, due to its reduced footprint when compared to a full Ada runtime system. This is significant because there is a safety-certification cost associated with an Ada runtime, which can be easily overlooked when focusing on the application and perhaps the real-time operating system. So, the small footprint of Ravenscar can reduce the safety certification burden and costs dramatically.  There are of course other benefits to reduced footprint in embedded devices in general,  some of these were discussed by Tomas Evensen in a recent blog.

Safety....a good thing to be thinking about when walking along the Ravenscar cliff-top path.