This page chronicles my ongoing work in the Vetronics Lab at Sussex University, where I'm carrying out research on x-by-wire technology and its applications to vehicular intracommunication. My current area of research is concerned with bridging messages between heterogeneous vehicle networking systems, but I seem to have taken up an array of other responsibilities including department webmaster, resident Java expert and part-time teaching assistant.
That all sounds terribly pretentious. None of it's inaccurate though. How did that creep up on me?
"In a modern vehicle network, safety critical systems must coexist with current deterministic networks such as MilCAN. Additionally, it may be advantageous to use MilCAN to monitor the performance of a safety critical system such as FlexRay.
Following a brief overview of both MilCAN and FlexRay technologies, the progress of an ongoing investigation into bridging the two standards is presented. The current solution is acceptable under test conditions, but unlikely to be suited to realworld use. Future plans extending the investigation on to new and more suitable hardware are then briefly discussed."
(Submitted to VPPC 2006. The paper itself was produced in something of a rush due to a severe lack of notice: consequently it is complete but not always best-worded, and suffers occasionally from disorganisation and repetition).
"Modern vehicle electronic networks are based mainly on deterministic protocols such as MilCAN, but in the future, it is likely that they will be required to coexist with safety-related networks such as FlexRay and TTP. These protocols are used in the civilian sector for powertrain electronics and X-by-wire, and as such they will likely be seen in future generations of military vehicle. It is advantageous to allow messages from one network to propagate to the other, since it allows systems monitoring and support for Integrated Survivability (IS) and Situational Awareness (SA). However, while a MilCAN network can be extended simply by adding devices to the bus, doing the same to a safety-related network risks severely compromising its function and reducing the integrity level of the system as a whole. This paper documents the development of a vetronics networking testbed designed to investigate the safe integration of deterministic and safety-critical networks."
(Submitted to RTNS08, yet to be accepted.)
My principal research is in the field of safety-critical systems in automotive technology, specifically intra-system networking over Flexray and MilCAN backbones. I'm currently working on a bidirectional Flexray/MilCAN bridge, so that incremental upgrades can be made to a military vehicle's command, control and communication system without requiring the entire system to be replaced.
Now to unpack that statement, since the number of people who will actually be able to understand it is fairly small. "Safety-critical systems" is an umbrella term that covers a variety of things, but in general it refers to equipment whose cost of failure in terms of risk to human life is unacceptably high. A safety-critical system will be engineered to specifications well in excess of its normal operating environment, with a series of fallbacks and safe failure modes, on the understanding that uncontrolled system failure cannot be allowed. A good example would be the control system of a nuclear reactor, where failure could easily result in meltdown or explosion, either one causing massive casualties. As a result, there are multiple circuit paths to each control system, so that fire or blast damage cannot easily cut off communications between the controllers and their actuators. In the event that communications are cut off, local systems should detect an out-of-spec heat condition and slot the control rods into place, shutting down the reactor. If the LOCAL systems fail, the control rod actuators are designed such that power loss causes them to disengage, and the control rods to fall under gravity into the shutdown position. This kind of multiple-redundancy and paranoid thinking is fairly typical of the safety-critical mindset.
Automotive technology, well, that's fairly obviously talking about cars. The connection between safety-critical engineering and vehicle technology is fairly obvious: what is less so is that the connection increasingly involves embedded computers. Electronic ignition and engine-management computers are fairly obvious, but ABS and other systems are becoming increasing computerised as well, and a modern car may need the respective computers to interact in a fairly complex manner to achieve a given behaviour. Increasingly, car manufacturers are moving towards an "x-by-wire" approach, in which every control input made by the driver (turning the wheel, pressing a pedal etc.) is turned into a data representation and sent over an internal network to control a motor (also known as an Actuator) that produces the desired result. One advantage of such a system is that a single control input can result in multiple systems operating. For example, if the driver punches the brake pedal suddenly while leaving their foot on the accelerator, the system can interpret their input as meaning "Stop NOW" and, as well as engaging the brake servo, it can declutch the drive train and close the fuel intake valves, temporarily cutting the accelerator and clutch pedals out of circuit as the car concentrates all it's resources on reducing its forward momentum.
Finally, intra-system networking. That's basically what I'm referring to in the above paragraph: all the vehicle's systems (and it need not be a car, the same systems with different peripherals are already in use by commercial trucks, military tanks and a broad spectrum of other vehicles) are interconnected and co-operating to control the vehicle. However, such systems cannot use Ethernet (the standard PC networking technology) or any of the common networking technologies such as USB, ATM and so on: they are not too slow, but too unreliable. There is a whole family of networking technologies that are used only in safety-critical and embedded networking because while they don't run at massively high speeds or carry gigabytes of information, they absolutely guarantee delivery within a given timeframe. You can put data in one end on a ten millisecond contract and, even if the system is fairly badly overloaded, if your data is of sufficiently high priority it will emerge at the other end no later than 9.999 milliseconds later. You can, no doubt, see how this is useful.
The two networking protocols with which I am working are Flexray and MilCAN. MilCAN is an older protocol that is widely used in both military and commercial vehicles, with a maximum bitrate of about 0.6Mbps. Flexray is a new protocol with a maximum bitrate of 10Mbps, with additional redundancy and flexibility for large irregular data transactions. Further information can be found by clicking the protocol names at the start of the paragraph. My current work involves designing and building a computer system that allows data to be transferred between Flexray and MilCAN networks with a minimum time-loss in transfer. This is useful because local systems may still speak MilCAN, but the bandwidth gain involved (not to mention the potential that newly-added devices speak only Flexray) may result in a backbone network that uses Flexray. In this situation, the utility of such a bridging system becomes clear.
My MSc project essentially revolved around the Flexray cluster on which I now find myself working. At the beginning of the project period I was presented with a stack of cardboard boxes and a large number of CDs and told "Here, this is your development cluster. Put it together, then use it.". The assembly process took a couple of weeks, given that I didn't have any manuals to direct my work and basically had to Zen the function of a large amount of complex hardware and software and assemble it in the right order.
Once the cluster was assembled, I was asked to produce a simple demo application. The lack of documentation and tutorials once again proved a slight obstacle, but I was eventually able to produce a simple application (a standard tick-tock: one node takes a variable, increments it and sends it to the other node, which increments it and sends it back...).
Finally, I began the project on which I am now continuing work: bridging messages between MilCAN and Flexray networks. By the end of the MSc I had a very basic bridge that tunnels MilCAN messages on the Flexray bus, with an average latency of 3.5ms. This is unacceptably slow for a real application, but a decent demonstration of the technology. My MSc ended here, and the DPhil is currently concerned with speeding up the translation, preferably by at least an order of magnitude.
