Paul Parkinson

nEUROn UCAV programme

In case you missed the news, the article 'COTS for unmanned flights' (Electronic Product Design, 22nd April 2008) describes how the nEUROn UCAV programme (Airforce Technology) has standardized on the VxWorks 653 RTOS.

nEUROn is a technology demonstrator programme involving five European companies, which in itself is not unusual, but it does have a significant objective - to demonstrate the maturity of technologies by producing modular safety-critical avionics systems running on COTS-based on-board computers. The development of avionics systems for a UCAV are in some ways even more challenging than for a military fast jet, given that it will provide a similar level of capability, but yet has less Space, Weight and Power (SWaP) available. This is one of the driving factors behind the ARINC 653 software architecture, enabling multiple applications to be hosted on a common computing platform (see 'ARINC 653 software weighs less' for background).

However, this advance results in a further challenge, that of being able to support modular and incremental certification of the IMA platform. This is necessary because of the very significant costs of safety certification under RTCA/DO-178B and EUROCAE ED-12B, especially at the higher software integrity levels (SIL). If an avionics platform comprising, say ten applications and several million source lines of code (SLOC) has been developed, and one of the applications undergoes an upgrade, it would be very time-consuming and prohibitively expensive to re-certify the whole platform. Alex Wilson covers these issues in more depth in his webcast 'Towards Incremental Certification with ARINC653'.

Fortunately, the experiences gained on recent IMA programmes in conjunction with the evolution of ARINC 653 standard has resulted in the mature VxWorks 653 implementation which fulfills these requirements and will provide a critical foundation for the objectives of the nEUROn programme.

I'll look forward to the nEUROn taking off in 2010.

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?

Mobile phones clear for take-off?

A few months ago I commented on some of the technical developments in passenger in-flight systems ('In-flight Internet access...and mobile phones too?'). In recent weeks, there have been some rapid developments, not on the technical front, but in terms of regulation and operation, with announcements from the UK telecommunications regulator Ofcom and the European Commission.

On the 26th March, Ofcom published the results of its consultation on the use of Mobile Communications on Aircraft (MCA). The executive summary summarizes the findings and Ofcom's decisions, but the full statement (PDF) provides much more detail, revealing a mixture of social, operational, safety and security issues.

The social issues which revolve around the acceptability of using a mobile phone in-flight, seem to have been brushed aside in the following statement:

3.9 Ofcom also understands the concerns expressed about peace and quiet on aircraft and the potential for mobile phone users to annoy other passengers. However we note that in similar cases which can lead to annoying behaviour, for example serving alcohol on board aircraft, it is a matter for aircraft operators to decide how to balance the services they offer to their passengers with the impact that they have. The airline industry is a competitive market and consumers generally have a choice between carriers: the provision of MCA services, and approaches to mitigating any annoyance, like quiet zones or quiet periods, could become part of the marketing differentiation between airlines. Further, Ofcom considers that UK consumers could be disadvantaged if MCA services were not permitted.

The comparison between serving alcohol and mobile phone use is unconvincing, because a passenger sitting in the next row having a drink is not likely to affect me unless they are drunk and unruly, whereas a passenger whose mobile phone and then talks loudly (to be heard over the background noise of the aircraft) will affect (i.e. annoy) me - I suspect a comparison between smoking in-flight and using mobile phones in-flight would have been more appropriate! For a more considered view on the social issues, I'd recommend Clive James' eloquent article 'I'm on the plane... the PLANE' (BBC Magazine).

The operational and safety issues are inter-related in some cases. For example, the proposed use of mobile devices is intended for use only above 3,000m altitude, and should be switched off during take-off and landing. However, once passengers become aware that mobile phones can be used at all on some flights, they are likely to become even more cavalier than they are at present (for example, on a recent return flight from San Francisco, a lady sitting across the aisle from me was using her BlackBerry  crackberry for email and phone calls while the plane was taxiing and only switched it off just before takeoff). Passengers probably won't distinguish between aircraft that have pico cells for mobile phone calls, and those that don't - the latter resulting in the mobile phone transmitting on increasing power levels in an attempt to connect to a base station, and thus increasing the risk of electromagnetic interference with aircraft electronics. These issues still need to addressed to the satisfaction to the UK CAA and EASA before mobile phones can be used in-flight over the UK and the rest of Europe respectively.

Some of the individual responses in the Ofcom consultation raised a number of security issues, however the Ofcom response was that this is responsibility of the DfT's Transport Security Branch but I couldn't find a responses or policy on mobile phone in-flight use on the Department for Transport's website.  The situation seems somewhat different in the US, where the Department of Homeland Security is openly opposed to the use of mobile phones in flight on security grounds ('Why US Airlines Still  Won't Join the Mobile Mile High Club').

The European Commission announcement (BBC News) makes it clear that the regulations not only allow for mobile data and text messaging services (which has been the focus of the recent trials by Airbus and Quantas), but also for both incoming and outgoing voice calls. Whilst the mobile network operators and airlines seems to be falling over themselves to introduce this technology, I can't help wondering whether this is what passengers actually want? It looks like I'm going to need to carry extra batteries for my Bose noise canceling headphones...

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-flight Internet access...and mobile phones too?

I read a business article in The Economist ('Mobile Phones on planes - Your call') during the Christmas holidays about the current developments in passenger in-flight systems, specifically the provision of Internet data access and the potential to support mobile (cell) phone voice calls during flight.

The article reports on trials of a Wi-Fi (Wikipedia) data service by JetBlue and Quantas, and a forthcoming mobile phone voice call trial by Air France (which follows on from the mobile phone SMS text messaging described in this Air France press release); it then goes on to discuss the social impact and acceptability of Internet data access and mobile voice calls during flight, which makes interesting reading.

The Internet, mobile phones and satellite communications have all been around for quite a while now, so you could be forgiven for wondering why we haven't seen these technologies rolled out across airline fleets before now? Well, maybe we are only just reaching the tipping point for technology (cost), and passenger demand (revenue)?

At present, the use of mobile phones in-flight is banned in the US by the Federal Communications Commission (and similarly by regulatory authorities in other countries) due to the potential for electromagnetic interference with aircraft avionics. If you perform a Google search, you might get the impression that this is a somewhat controversial subject with polarized views, but there is an example of hard experimental data to support the position on the UK Radiocommunications Agency website EMC Awareness page. There's also the problem that mobile phones passing over ground mobile networks at high speed could cause disruption as the networks struggle to perform handover from one cell to the next.

These new in-flight systems make use of a miniature base station on board the aircraft, known as a  picocell (Wikipedia), which connects to a satellite communications network to avoid both of these problems. This works because mobile phones transmit on increasing levels of power until they get a response - the concept is that if they receive a response from a nearby picocell they continue to transmit on low power levels, which will not interfere with aircraft avionics or reach ground-based networks thousands of feet below.

Despite this technological advance, I have to admit that I would try to avoid being on a flight where mobile voice calls were possible. This has nothing to do with the safety aspect, but because of the disruption. People tend to talk more loudly on mobile phones than on land lines because the sidetone on mobile phones is less than on landlines (sidetone is where the speech from the microphone is redirected to the speaker at a lower level, so that the person can hear what they are saying). If you now factor in the noise from the air-conditioning and jet engines, you've got a recipe for loud background chatter. The Economist article doesn't mention if these systems will support in-coming voice calls, but I certainly wouldn't welcome the sound of ringing mobile phones either, especially on a transatlantic flight, especially when I am trying to get some sleep! Maybe the reason why the airlines are being cautious about the introduction of voice calling is because they are wary of adverse passenger reaction?

On a positive note, I would very much welcome in-flight Internet data access, as it enable me to catch up on my email backlog, especially on long transatlantic flights. As an aside, my view on this isn't affected by the news story 'FAA: Boeing's New 787 May Be Vulnerable to Hacker Attack ' (Wired.com) which was posted earlier this week and was rapidly seized upon and somewhat sensationalized by the wider media. The Wired article, includes mention of "multiple networks", "isolation" and "air gaps" (i.e. physical separation) but doesn't really explain the concept of aircraft networks, which would have provided some useful context.

Basically, aircraft have a number of different type of networks, or domains, which connect systems which perform different functions; these typically include Flight Deck, OEM, and Passenger Systems. The networks have different networking requirements and are separated by firewalls for safety and security reasons (see ARINC 664 for more details) - one aircraft design already in-service is reputed to use a hardware diode to only allow the flow of data in one direction only between networks. In any case,  so I don't think this story should be a cause for concern for 787 passengers. Back to in-flight Internet access, I wonder if other laptop users would be trying to use Skype to make Voice-Over-IP (VOIP) calls? If so, I hope they don't sit near me.

So Is it finally time for take-off for in-flight Internet access?

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!