Paul Parkinson

Astute optronic mast case study

I don't often have the opportunity to discuss how Wind River's Aerospace and Defence customers are using our technologies in their applications due to security restrictions and commercial confidentiality.

So, I am very grateful to Thales for allowing us to announce that they have used VxWorks for their latest generation optronic mast which is being used on the UK Royal Navy's Astute class submarines.

If you're interested in the challenges Thales faced in migrating their Ada application from a custom Digital Signal Processor (DSP) architecture to COTS multi-processor PowerPC architecture running VxWorks, and how they overcame them, the case study (PDF) has recently been published on the A&D Customers page.

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).

Killer Robots or Killer Headlines?

I've been tracking the developments since the publication of the article 'Non-Answer on Armed Robot Pullout From Iraq Reveals Fragile Bot Industry' in Popular Mechanics. The article covered the recent RoboBusiness conference and had highlighted the fact that three SWORDS armed robots which had been deployed to Iraq in 2007 and had subsequently been withdrawn. Popular Mechanics cited the US Army's Program Executive Officer, Kevin Fahey, who reportedly said that there was an incident where "the gun started moving when it was not intended to move".

The article didn't go into any further details about the circumstances in question, but that wasn't enough to prevent some hysterical headlines in a number of blogs, for example: 'Combat Robot Attempts Rebellion Against Human Masters in Iraq, Army Pulls Plug for 10-20 Years' (Gizmodo), and 'US war robots in Iraq 'turned guns' on fleshy comrades' (The Register).

Neither article made any reference to the fact that although SWORDS is armed it is NOT autonomous, but is remotely operated by a soldier. The distinction is an important one, as the prospect of armed autonomous robots raises a whole set of issues (as I mentioned in an earlier post 'Autonomous military robots'); whereas, having a 'man-in-the-loop' places the responsibility for making decisions and accountability on the human operator rather than on the machine.

However, it seems that the manufacturers Foster-Miller are concerned about the adverse publicity and have even updated the product description on their website with an editorial comment. (If you want to learn more about the intended role of SWORDS, there's some information on page 17 of The Guardian, Winter 2007 (PDF) and also on DefenseLink).

Interestingly, Popular Mechanics has subsequently published 'The Inside Story of the SWORDS Armed Robot "Pullout" in Iraq: Update' which clarifies the statements made in the earlier article; however, I couldn't help thinking that this presents the story in a slightly different light?

Active Driver Assistance

I recently received a brochure for the new Audi A4 which has its UK launch on 23rd February, so I guess Audi must think it's time for me to trade in my A3, which had its 120,000 mile (190,000 km) service last week. Flicking through the brochure, I noticed a number of new technologies being introduced on the new A4 model. The Audi Drive Select features comfort, auto and dynamic drive modes; Audi Side Assist uses radar sensors to detect vehicles in the car's blind spots; and Audi Lane Assist warns if the car strays from the marked lane. Back in the 1990's, I attended a lecture given by Jaguar about the PROMETHEUS research programme (IEEE), which was investigating some of these technologies, as well as others such as Head-Up Display systems (which are now being offered on some executive cars).

However, the feature on the A4's options list which really got my attention was the Adaptive Cruise Control, which the Audi brochure describes as follows:

The optional adaptive cruise control automatically regulates the distance from traffic ahead. If a car ahead of you slows down, the system also reduces your speed. If the vehicle in front brakes suddenly, the system first warns the driver acoustically before applying the brakes briefly if necessary.

I find this rather unnerving, as adaptive cruise control crosses the line between a passive driver assistance system and an active driver assistance system, i.e. one that takes control away from the driver.

Now don't get me wrong, I've got nothing against electronic driver aids, especially as on one occasion if it were not for the Anti-Lock Braking System (ABS) and Emergency Brake Assist (EBA) I wouldn't have stopped in time for a pedestrian who simply walked out in front me without looking where they were going. Most electronic driver aids take their input from the driver but don't override the driver's control (except for Electronic Stabilization Programme, but that's when the driver has already lost control), and they also usually have a fail-safe mode, reverting to the default behaviour without electronic assistance.

However, I am concerned about the potential for adaptive cruise control to make an incorrect decision and increase the risk of an accident rather than reduce it. For example, if I was approaching a car in front of me, and anticipating a gap in the traffic to change lanes to overtake, if the adaptive cruise control applied the brakes to slow my rate of closing on the car in front, it could put me in danger if there was a car approaching in the overtaking lane. I'm not ready to let a car make this judgment for me.

Now that these systems are capable of taking active control of the vehicle, they must surely be regarded as safety-critical systems. Some of these electronic systems may have undergone ISO/IEC-61508 functional safety certification on the basis that 'the equipment under control poses a threat to its surroundings', but how can we be sure that this standard will be applied consistently by different automotive manufacturers and suppliers to the development of the software in these systems, given that there are likely to be different perceptions and interpretations of safety in diverse geographical markets? This is something of which the automotive industry is already aware - see "The Application of IEC61508 in the Automotive Industry" (Ekkehard Pofal, PDF).

I hope that this will lead to the development of automotive domain-specific safety levels which could become the basis for international standardization. The DO-178B / ED-12B avionics software standard defines software levels in relation to the consequences of failure creating increased workload on the pilot and the potential for causing death or injury. There are some similarities here between the aerospace and automotive sectors, as I mentioned in a previous blog, and maybe the automotive industry could benefit from the lessons learned in avionics safety certification?

So, let's hope that Vorsprung durch Technik is heading in the right direction.

Managing Software Obsolescence

Yesterday, I attended the Component Obsolescence Group (COG) quarterly meeting, which was held at the Imperial War Museum, Duxford.  I was standing in for my colleague Alex Wilson, who wasn't able to attend, and I gave his presentation 'Managing Software Obsolescence through Standards'.

The presentation was about how open standards and software abstraction can provide isolation from underlying hardware architectures, and can assist processor architecture migration as part of a technology refresh cycle. This is important in many A&D programmes, given in the increasing in-service lifetimes of some systems, but the principle also applies to other vertical markets too. The presentation also highlighted how the RTCA/DO-297 standard provides guidance on the development of Integrated Modular Avionics (IMA) platforms to enable modular and incremental certification of safety-critical systems, but this actually provides a side-benefit which can help address obsolescence. This is because it advocates a role-based approach, and advocates separation of the configuration data based on role and activities. 

This approach can be used in conjunction with a MILS (Multiple Independent Levels of Security) separation kernel, which is designed for hosting applications of multiple security classifications on the same processors, but can also be used as a framework for software isolation to assist in managing obsolescence.

Some approaches to hardware obsolescence were also discussed during the meeting, and I was interested to hear how hardware & software emulation of a legacy processor are being used to extend the lifetime of a safety-related industrial system. I was struck that there's more similarity between the challenges of some A&D programmes and other markets than I had first thought.

I also took the opportunity to wander around Duxford's new AirSpace exhibition with some of the other delegates during the lunch break. If you haven't been yet, it's well worth a visit.

In-Service Evidence

The UK Ministry of Defence recently announced that its Chinook helicopter HC3 variants will undergo a £90.1m ($181m) upgrade. The press release itself is rather brief, but the story in Flight Global ('UK signs £90 million deal to fix grounded Chinook helicopters') gives a bit more background. However, to really understand the purpose of the upgrade, you need to cross-reference information from a number of sources: Chinook blunder 'left RAF short' (BBC News), Wikipedia entry for Chinook HC3, and a UK National Audit Office report (PDF). I'll leave the political issues well alone, but some of the technical challenges really interest me.

In brief, the HC3 is based on the US Army's MH-47E Chinook helicopter, but has been customized for use by the UK RAF 7 Squadron Special Forces flight. The enhancements include improved range, night vision sensors and navigation capability. However, in order to fit all of this additional capability into the cockpit, a unique hybrid digital/analogue avionics system which was reliant on software was employed.

The delivered HC3s fulfilled all the requirements specified in the contract, but unfortunately the contract didn't specify that the software and documentation should be developed in accordance with UK defence standards (UK MOD Def Stan 00-55/00-56), so it was impossible to prove that the flight systems met these standards. In addition, because the cockpit systems are significantly different from the fully digital cockpit used on other Chinook variants, the in-service evidence for those aircraft is not relevant to the HC3.

Since the delivery of the HC3s, the UK defence standard Def Stan 00-56 has been revised, and the latest version (Issue 4, 2007) makes greater provision for use of processes used in and software developed under other safety standards (e.g. DO-178B, ISO/IEC61508), so that shouldn't present an insurmountable technical barrier for systems developed according to DO-178B. However, this case does raise some interesting questions in general about the use of in-service evidence in safety certification:

• When is it appropriate to use in-service evidence as part of a safety case?
• At what point do customizations to a previously deployed system render the in-service evidence invalid?
• Is an in-service evidence approach acceptable for avionics systems at different levels of safety criticality; secondary guidance instruments perhaps, but what about primary flight controls?

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)...

Military Aerospace & Electronics Show

Yesterday, I attended the UK's Military Aerospace & Electronics technical conference and exhibition, which was held at the Heritage Motor Centre. The technical conference was split into three technical tracks, which were broadly related to avionics, land systems and technologies; and as is sometimes the case at these conferences I found that I wanted to attend some presentations which were running concurrently!

At a high-level, there were recurring themes amongst the presentations relating to modularisation, reconfigurability and of course, security. Some of the presentations discussed these issues in the context of the Future Rapid Effects System (FRES) programme, which is broadly speaking the UK equivalent of the US Future Combat System (FCS) programme. It was interesting to hear how future upgradeability through planned obsolescence and technology insertion prior to deployment, and the recognition that standards-based open architectures could facilitate this requirement.

Michael Morua of Atkins Defence Systems (MOD-appointed Systems House for FRES) gave a technical presentation on how the FRES Electronic Architecture (EA) is being implemented using a service oriented architecture, and even explained how reconfigurability would be achieved through open interface standards, and interfaces to external systems could be implemented through common data exchange middleware.

I always appreciate the opportunity to learn about emerging technologies at these conferences, so I was glad that I attended Peter Allsopp of GE Aviation's (formerly Smiths Aerospace) technical presentation 'Networked Aerospace Systems - Future Data Network Technologies'. It was interesting to hear how as data throughput requirements for avionics networks increase, the determinism, latency and availability requirements become harder to maintain with current avionics networking technologies. It appears that FlexRay, an open standard for time-triggered field bus technology may provide the way forward.

FlexRay was originally developed for safety-critical automotive applications, so it's encouraging to see that avionics can potentially benefit from the more widespread deployment of technologies in the automotive sector. This suggests that there can be cross-fertilisation between aerospace and automotive in both directions (blog: Can Automotive learn from Avionics Safety?).

Vulcan returns to the skies

I've been trying to keep track of aerospace news recently by using using various Google Alerts and subscribing to news feeds, but one story I nearly missed during the build up to the the Dubai Air Show the story 'Vulcan bomber returns to the sky' (BBC News). This relates to a team of enthusiasts at Vulcan to the Sky Trust who have spent ten years restoring a Vulcan bomber (WingWeb) to flight, and have successfully flown it again.

I have to admit that I am a bit of a fan of the Vulcan, probably because of its distinctive delta-wing design, which happened to be fortuitously stealthy and gave it an agile appearance.

(This picture is one of XJ824 Vulcan which I took at Duxford in 2005, not the XH558 Vulcan which is flying again. There are some great photos of XH558 flying again on the Daily Mail website here).

Leaving nostalgia aside, the restoration is an impressive achievement, not just because of the costs involved (£6.5m), but also the technical challenges and obsolescence issues for an aircraft that hasn't flown for fourteen years. 

Obsolescence is of course a major problem facing many military aircraft, particularly those which have long and extended in-service lifetimes such as the B-52 (wikipedia), but also more recent designs. The aerospace industry is now trying to proactively address this problem through planned obsolescence, which has an impact on the architecture and design of both hardware and software. COTS can play an important role here, but the benefits of COTS in terms of upgradeability and interoperability can only be achieved by using open standards-based architectures.

This was one of the main topics which I covered in my paper 'The Challenges and Advances in COTS Software for Avionics Systems' at an IET seminar in September - if you would like to read it, the paper can be downloaded from here: [PDF] (size: 200kb).

Next week, I will be going to the UK's Military & Aerospace Electronics Show, which will have a number of speakers covering topics relating to obsolescence, networking, security and other areas. My colleague, Alex Wilson, will be presenting 'The evolving ARINC 653 standard and its application to IMA'. Hope to see you there!

ARINC 653 partition jitter & scalability

Last week, I was looking at a customer's avionics software architecture to determine whether it might be possible to migrate this to an ARINC 653-based Integrated Modular Avionics (IMA) environment. This raised some interesting questions in terms of performance and scalability.

If you consider the implementation of an avionics system using an ARINC 653 software architecture, the RTOS enforces temporal partitioning of the safety critical applications running in the individual partitions through the use of ARINC 653 time slot scheduling.  (ARINC 653 defines a schedule consisting of major frame comprised of a sequence of minor frames which specify the execution time of an individual partition for a fixed duration; at the end of the major frame the schedule repeats). However, the ARINC 653 scheduling implementation needs to be deterministic, i.e. the next partition should start execution at the exact time predefined in the ARINC 653 schedule, or very close to it. The delta between the defined time and the actual time is known as partition jitter.

So, what approaches can be used to minimize partition jitter?

Let's consider the ARINC 653 architecture - it actually performs two types of scheduling: (1) time slot scheduling of the partitions; and (2) priority-based preemptive scheduling within the partitions. Let's assume that the RTOS is running in the processor's privileged supervisor mode, and the applications are running in the processor's user mode and in different memory contexts (in order to provide spatial partitioning - another key requirement of Integrated Modular Avionics).

Now, if the time slot scheduler and the priority preemptive scheduler are both implemented in the RTOS kernel, this could create a significant overhead for the RTOS kernel in handling a significant number of system calls associated with each processes context switch within a partition. This could lead to performance degradation as the number of partitions in the system increases (as the ratio of the total number of processes and partitions divided by the major frame duration is likely to increase also).

However, an alternative approach would be to only implement the time slot scheduler in the RTOS kernel, and implement the priority preemptive scheduler within the partition in user mode. The advantage of this approach is that the priority preemptive scheduler can perform schedule application processes in user mode without having to perform a system call into the RTOS kernel and the associated overhead of user/supervisor context switch. This approach not only helps to minimize partition jitter, but also make the architecture very scalable, which is why it is used in VxWorks 653. (I mentioned this scalability in an earlier blog, where VxWorks 653 was running with sixty-five ARINC 653 partitions at Avionics 2007 Show in Amsterdam).

Of course, it's also important to be able to detect at runtime whether partition jitter ever exceeds a predefined threshold, and VxWorks 653 implements this through the Temporal Violation Detection  mechanism, which would raise an alarm to the Health Monitoring System.

By the way, the phrase Temporal Violation Detection sounds more like a concept from Einstein's Special Theory of Relativity (wikipedia) than software engineering, but I don't think we're going to have to consider the impact of Time Dilation (wikipedia) in ARINC 653 systems just yet, as we're still a long way from traveling close to the speed of light...