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.

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.

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

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

Integrated Modular Smartphone?

The title of this blog might suggest that I've got mixed up between Integrated Modular Avionics (IMA) and consumer devices, but if you bear with me, I'll try to explain why I think there are some parallels.

I was recently given a shiny new smartphone (wikipedia), which will enable me to keep up to date with important emails when I'm out of the office, rather than get a couple of days behind which can happen  sometimes when I'm travelling.

Actually, I was quite pleased to receive the smartphone because, as an engineer, I like cool gadgets anyway, and also because it means that I am able to carry around one device instead of a mobile phone and a PDA. This will also please my wife, who complains that carrying all of these devices around is ruining the lining of my jackets. Anyway, there aren't any suitable alternatives...unless you're Joey Tribbiani in Friends ('The One with Joey's bag', wikipedia).

For the last few years, I've been using a Nokia 6310i mobile phone and a Palm Tungsten T5 PDA. They are both very competent at the providing the functions for which they were designed.

The 6310i is not the latest-and-greatest gadget phone by any means, but is an extremely capable business phone. It's triband (works in Europe and the US), has excellent range, and the lithium ion battery can last nearly a week before needing to be recharged. It also has Bluetooth, Infra Red and GPRS enabling me to connect to my headset, laptop PC and the Internet.

I would be lost without my Tungsten T5, quite literally, because as well as having all the usual Palm applications (Contacts, Calendar, Memos, Tasks, Documents-To-Go, etc.), I also have TomTom Navigator in-car satellite navigation software and a portable Bluetooth receiver.

So, I had high hopes about the prospect of integrating all of this functionality onto a single device, enabling me to carry less with me in my jackets, and also fewer chargers and cables in my laptop bag.  In this respect, the smartphone can be viewed as reducing SWaP (Space, Weight and Power), by integrating the functionality of multiple federated devices but on a single integrated modular system.

However, after having spent some time using the smartphone, I realized that it wasn't performing as well as I would have liked, in two areas:

1. Power consumption
   I expected that the smartphone would have greater power consumption than my Nokia 6310i, but I was surprised by the fact that if I have Bluetooth (for headset) or GPRS (for email) enabled for any length of time, the battery drains very rapidly indeed. This means that the smartphone barely last 24 hours between recharging which severely limits its usability. I'm surprised that the software isn't optimised to automatically put some of the devices into low-power mode when not in use.
2. Application integration and portability
   I had kept all my contacts in my Palm Tungsten PDA, and I wanted to migrate all of this data to Microsoft Outlook on the smartphone, but despite there being options to export and import data between the applications in several formats (e.g. comma separated, tab separated), these could not handle records with fields in different orders and sometimes partially complete records. In addition, the smartphone will not import the contacts from my SIM card into the Outlook address book, which means when someone in my SIM card calls me, their number is displayed but not their name. Overall, my contact and address data is fragmented in multiple locations, with has the potential for duplication and inconsistencies.

I couldn't help thinking of the differences between my experience with of rather poor integration with the smartphone, and what's being achieved with Integrated Modular Avionics and ARINC 653 (see my earlier post 'ARINC653 software weighs less' for details). Firstly, IMA architectures are saving space and weight and power (the weight saving alone is around 500lbs on a some wide body jets);  and secondly, applications written by different parties (and even using different programming languages) can communicate with each other through ARINC 653 ports. I can't help but think that the use and development of open standards such as ARINC 653 has got to be a significant factor in interoperability and portability. Maybe there's a lesson there for smartphone manufacturers...

Police drone

Just to avoid any confusion, I want to make it clear that this blog ('Police drone') has nothing to do with the forthcoming world tour by the rock band The Police (Wikipedia), but rather the forthcoming trial of an unmanned air vehicle (UAV) by the Merseyside Police force in the UK for "tackling anti-social behaviour and public disorder" ( 'Pilotless police drone takes off', BBC News). 

The BBC News story, and a related article 'Police spy in the sky fuels 'Big Brother' fears' (The Telegraph) focus on the use of the technology in reducing crime, and also the increasing use of surveillance in society, which is a somewhat controversial issue in the UK at the moment as it has the most CCTV cameras of any European country.

However, my primary interest was in the technical aspects of the microdrones UAV and its operational parameters - it weighs less than 1 kilogram, uses carbon fibre rotor blades and can fly at altitudes of up to 500m (1640ft). It can carry CCTV or night vision cameras a which can stream images to a police ground vehicle, and it can be fitted with on-board GPS navigation systems.

This is an impressive technical achievement, but I have a number of safety concerns about the use of these small UAVs operating in a densely populated urban environment, specifically:

1. Can we be sure the ground pilot will always have line of sight visibility to the UAV? In an urban environment, the ground-based pilot's field of view could be obscured by tall buildings, which could have consequences in terms of an aerial collision or a ground collision, possibly involving people.
2. When flying by pre-programmed GPS navigation, how will the UAV perform 'see and avoid' of other aerial vehicles, and also terrain collision avoidance? Are the control systems safety certified? How can we be sure that it won't wander into the flight path of other aircraft operating in the vicinity (e.g police helicopters), or with civil aircraft taking off from on on landing approach to Liverpool airport.

Although the UAV does not weigh much, a collision with helicopter rotors or an aircraft jet engine could cause considerable damage - even a Canada goose colliding with a passenger jet can cause cabin depressurisation: Photo 1, Photo 2 (Aviation Safety).

The UK distributor is reported in the Telegraph article as saying the microdrones UAV is not subject to UK CAA regulations because it is "a toy". I am not reassured by this rather sweeping statement, especially in the light of the SkySeer UAV crash (IET) last year, which was operated by the Los Angeles Police Department Sheriff's Department (LASD) without FAA approval.

I'm aware that the situation was quite complex as there is a diverse range of air vehicles from model aircraft, through UAVs to manned aircraft, and there are also the different types of airspace to consider. So, I thought I'd do a bit of research, and fortunately, there is plenty of relevant information on policy and guidelines on the CAA website. In particular, 'CAP 658 - Model Aircraft: A Guide to Safe Flying', 'CAP 722 - Unmanned Aerial Vehicles Operation in UK Airspace' and 'UK CAA Policy for Light UAV Systems' (PDF).

On reading CAP 658, I noticed that the definition of model aircraft only applies to those used "for sporting and recreational purposes...", so the use of a UAV for law enforcement activities doesn't appear to fit this definition.

However, the Light UAV System definition seems more appropriate in this case, and here the CAA guidelines clearly state: "Operational constraints include line-of-sight operation at a range not exceeding 500 metres from the UAV-pilot, and at a height not exceeding 400ft above ground level".

So this would seem to place at least some constraints on the operation of the drone, but are they sufficient alone?

Well, now having droned on (if you'll excuse the pun) about safety, I don't have any space left in this blog to  discuss security issues (control link security/interference, data  link encryption, etc.), so maybe I'll just mention that the control frequencies are published on the microdrone website? Discuss.

Military Avionics Technology Exhibition, UK

Last week I had the opportunity to attend the Military Avionics Technology Exhibition arranged by the UK MOD, and held at the Defence Equipment and Support Agency's Abbey Wood headquarters. This  was an impressive venue, although I don't think I quite got used to the 'Bomb Shelter' signs on the deep walls of the lecture theatre and exhibition hall no matter how often I glanced at them.

The event started with a talk by Air Cdre George Baker, who discussed a number of issues related to through-life capability, which was a recurring theme in the subsequent industry presentations. I often find at these sort of events, that some of the presentations will bring up something completely new and/or unexpected, and this was no exception.

Neil MacTavish of Nallatech gave a very insightful presentation on the use of reconfigurable computing in airborne applications, and described a case study involving an unmanned air vehicle (UAV) using of 3 CCD cameras and reconfigurable processing nodes to achieve "see and avoid". This system was able to detect an aircraft approaching at 1.5 nautical miles, including aircraft below (which can be difficult to detect against the ground). If these results can be obtained in the visible spectrum, imagine what can be achieved with multi-spectral and hyper-spectral sensors? This could be a significant step in overcoming the technical barriers of UAVs operating in non-segregated airspace, provided of course that the software was safety certified to the appropriate level.

This is something that I discussed in the earlier blog: UAV Roadmap, and also in a paper which I presented at the Wind River Regional Developer's Conference in Stockholm in March - that was another event where I learned a lot - but about space from Wind River's Mike Deliman, and in particular the Mars Rovers. Mike will be around to talk to people at our forthcoming Regional Developers Conference in Manhattan Beach (Los Angeles), but if you're on this side of the Atlantic, you might  want to come along to one of our European Aerospace & Defence Seminars. I can't promise any beaches, but we will be presenting some leading edge technologies.

Hope to see you there!

Autonomous military robots

In an earlier blog, 'A robot in every home', I commented on some of the issues related to the development of robotics software, in particular in relation to open standards and safety-criticality. This was in the context of domestic and industrial robots. Now it seems that the issue which is causing debate in the scientific community is prospect of deployment of autonomous decision-making military robots  ('Robot future poses hard questions', BBC News).

There have been significant advances in the development of robotic systems for military applications in recent years, the DARPA Grand Challenges in 2004 & 2005 having been successful in encouraging the advancement of autonomous systems for battlefield environments. Later this year, the DARPA Urban Challenge, as its name suggests, will present different technical challenges, as the autonomous vehicles will need to manoeuvre in mock city environment  "executing simulated military supply missions while merging into moving traffic, navigating traffic circles, negotiating busy intersections, and avoiding obstacles". Some of the competitors have already developed advanced sensors for this challenge, and it's claimed that in addition to being used in autonomous military vehicles, these systems could provide benefits for civilian systems, including driver assistance. However, as I mentioned in my blog 'Can Automotive learn from Avionics Safety?', I think there's an important distinction between passive driver assistance systems AND autonomous systems or those which take control away from the driver - the difference being the matter of safety.

In my view, there are two issues here:

1. Is the software 100% reliable for the functions that is designed to perform (i.e. is it safe, has it been tested properly)?
2. What limits or safeguards can be placed on the system beyond its defined operating parameters?'.

These are important questions for when you take a human being out-of-the-loop, because despite all our flaws, we can still make decisions in unanticipated scenarios, whereas pre-programmed computers by definition cannot. In the case of an unmanned ground vehicle, an unanticipated scenario could result in a collision, and possibly even fatalities.

However, more worrying is the prospect of armed autonomous military robots which could make errors with catastrophic consequences. This is no longer in the realms of sci-fi, as the BBC story mentions, as Samsung has developed the SGR-A1 armed robot (The Register). There's an interesting promotional video on Techblog which shows a soldier surrendering to an SGR-A1 (which I find strangely reminiscent of the OCP board member surrendering to the ED-209 robot (wikipedia) in the movie Robocop, immortalized by the line "You have 20 seconds to comply...").

Let's consider a few scenarios for a moment. These robots have advanced image sensor systems, but can they reliably distinguish between a friend and a foe, an armed combatant and an unarmed soldier surrendering, or even identify a child playing with a toy gun? We have a long way to go before robots achieve the reasoning capabilities of Star Trek's Lieutenant Commander Data (wikipedia).

So, I am with the scientists on this one, I think we need an informed debate....

Avionics 2007 Amsterdam

In my previous post I mentioned that I was heading off to Amsterdam for the Avionics 2007 event, so I thought I should post some comments on the exhibition and conference. The exhibition was pretty focused, with a good mix of COTS hardware and software suppliers, and systems integrators. Walking around the exhibition a couple of things struck me.

Firstly, that there seems to have been a significant amount of consolidation amongst the COTS hardware suppliers recently, with companies such as Curtiss Wright Embedded and  GE Fanuc Embedded now able to supply not only rugged single board computers (SBCs), but a vast range of building blocks needed to build a complete avionics hardware platform, including sensor I/O modules, avionics databuses and even graphics displays.   

Secondly, the integration between all of these hardware modules and their many possible permutations is only possible to due to the use of standards-based interfaces: ARINC 429, AFDX/ARINC 664, MIL-STD-1553B, IEEE 1394, VMEbus, CompactPCI, Advanced TCA... you get the idea.

During the conference, the concepts of '4D' Air Traffic Management (ATM) and removing barriers in the current ATM system were prominent, especially with the increased amount of air traffic from Very Light Jets (VLJs, wikipedia) and Unmanned Air Vehicles (UAVs). This radical approach involves removing the human from the loop (i.e. the pilot) and allowing an aircraft's Flight Management Systems (FMS) to calculate, negotiate, execute and monitor 4D trajectories.

This is somewhat controversial at present, but at least in a manned aircraft the pilot is able to take control in the event of system failure or to avoid a collision. In an UAV, this approach would be dependent on the UAV's systems being able to perform this 4D navigation 100% reliably and accurately, and being able to perform Sense and Avoid to the same level as a manned aircraft.

I believe that this is a significant challenge, because in addition to needing sophisticated sensors and intelligent processing algorithms, it will also require the software systems to demonstrate an equivalent level of safety as a manned aircraft. To me, this means that the UAV software systems will need to be safety certified to at least the same level under RTCA DO-178B / EUROCAE ED-12B as on a manned aircraft. To allow uncertified systems to control flight in non-segregated airspace could be potentially catastrophic.

An interesting side-effect of the 4D ATM approach, is that it would require increased interoperability between civil ATM systems and tactical military avionics systems. This raises some interesting questions about Information Security, in particular how to ensure that Top Secret mission data is not disclosed to an Unclassified civil ATM system, but maybe that's a subject for another blog.

Avionics 2008 has already been scheduled for 7-8th March, and I hope to have the opportunity attend again next year, and hopefully visit the excellent Restaurant De Roode Leeuw (Red Lion restuarant) again too.