Paul Parkinson

Active Driver Restraint

I blogged last year on Active Driver Assistance and noted my concerns about the potential for adaptive cruise control to make an incorrect decision and increase the risk of an accident rather than reduce it.

So I was interested to hear a BBC news report earlier this week about a device which automatically stops acceleration when a vehicle exceeds the speed limit going on test in London. Intelligent Speed Adaptation (ISA) is being developed by Transport for London (TfL) and uses a newly-introduced digital speed limit map of the city. On the Radio4 Today programme, journalist Quentin Wilson said that anything that takes away driver control has to be looked at carefully.

The levels of interventions are reported as: 

• Advisory ISA: the driver is informed of the limit and of violations but there is no direct link between this information and the vehicle controls.
  

• Voluntary ISA: the system is linked to the vehicle controls but the driver can choose when to have the system enabled.

• Mandatory ISA: no override of the system is possible.

I can appreciate the potential benefit of an Advisory ISA, but this capability has been available for quite some time in proven systems such as Road Angel (which has an interesting heritage); however, as I mentioned in my earlier blog, I still don't think the arguments for voluntary/mandatory ISA are convincing...but if the Mandatory ISA scheme were to be introduced in London, I'm sure that my brother's BMW M5 would be in need of a new home.

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.

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

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

Can Automotive learn from Avionics Safety?

In my previous post on software safety standards, in response to some questions raised by Alex Wilson, I commented on what I believe are signs of convergence between avionics software standards. However, I didn't address Alex's question on whether there is any potential for convergence between avionics and automotive software standards.

Electronic systems have been present in automotive systems for many years now, but they have only really become visible to the driver and passengers with the advent of infotainment systems and driver-assist systems, such as Anti-Lock Braking System and airbag Supplementary Restraint Systems (wikipedia).

These systems could be viewed as passive systems, as they do not take control of the vehicle away from the driver, but there are now also advanced driver assistance systems (ADAS) emerging on premium brand vehicles which can improve the driver's situational awareness, these include Lane Departure Warning systems and Infa-Red (IR) night vision systems. There's a very good overview of these developments at DaimlerChrysler on Prof. Dariu Gavrila's website, including an overview and a technical paper PDF; and there's also an good online article by Gaganjot Maur on the Automotive Design Line website, but neither of these articles really address software safety, which is what interests me.

The question I want to ask is this: Is there a point at which drivers become dependent on these driver assistance systems, and what would be the consequences of their failure (if we can use DO-178B avionics style comparisons for a moment)?

For example, I frequently use a satnav application (wikipedia) for traveling in my car, but only as a secondary guidance instrument (to use avionics terminology for comparison), i.e. it gives me directions and I decide whether they are sensible and choose to follow them or to ignore them - so I have not followed it blindly into a river yet, unlike a driver in Germany (Yahoo News). However, imagine that I was driving across unfamiliar country lanes at night, and used the satnav's 3D visual display to anticipate the next bend in the road, beyond the range of my headlights? At this point, I would be relying on the satnav display, because I would not have any independent frame of reference, so this would have consequences in terms of safety.

This is of course a rather contrived example, but it is representative of some of the ADAS systems which are being developed. So should we expect a similar level of rigour to the software development and safety certification for these automotive systems that we would if they were avionics systems?

Which software safety standard would apply? I am aware that ISO/IEC-61508 is being used for functional safety in some systems, but it doesn't appear that it is being used consistently across the industry? Is it time for standardisation in automotive?

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.