Search Results

All functional safety standards have some definition of “risk” and the automotive standard ISO 26262 is no exception. Risk is related to the exposure, the severity of the outcome, and in the case of ISO 26262, the controllability in relation to a specific vehicle hazard or hazards associated with the behavior of the vehicle or part of the vehicle. Thus hazards are central to understanding the risk associated with systems. When considering traditional power train systems, based on internal combustion engines or centralized electric motors, hazards are most usually limited to unintended acceleration and deceleration. The situation is complicated somewhat with the introduction of electronically controlled differentials, which can induce limited amounts of induced yaw, as can ABS and ESC. In a similar manner, replacing the centralized driveline system with in-wheel electric motors brings with it a similar set of issues.

Compact direct drive in-wheel motors with integrated inverters, control and brakes offer a number of distinct advantages compared to conventional electric drive systems. The most obvious being that the drivetrain is now packaged within the wheel freeing up space elsewhere, in addition many driveline components and their associated losses are eliminated and the vehicle efficiency, response and handling can be improved. In new vehicle applications this allows complete freedom for designers to optimize the vehicle layout, have more usable space inside the vehicle body and enables revolutionary vehicle concepts (which will become more important as road space becomes scarce and taxation measures migrate towards vehicle size). In retrofit applications the compact package allows an electric drive to be added to any existing vehicle without requiring any significant disruption to the vehicle platform to keep integration costs down.

Pi Technology has been working on hybrid propulsion systems for its various customers for several years, including the Ford Fuel Cell Focus and Hybrid Escape. The systems we have worked on cover a wide range of technologies, from fuel cell/battery and engine/battery systems to hydraulic based systems. As a result we are only too aware of the multitude of issues that need to be addressed. Each of the systems when viewed in isolation appears to be completely different to each of the others; however, we have found this not to be the case, in that common architectural challenges have emerged from each system. In this paper we review the issues we encountered on two early hybrid projects and discuss our experimental efforts at creating a unified control strategy framework for combining different components, in a way that provides a consistency of view between the individual subsystems and the system as a whole.

Pi Technology and the Ford Motor Company are using MATLAB Simulink/Stateflow model based design and automatic code generation in C, for the main software development for three electronic control units targeted at the Ford Focus fuel cell vehicle. The automatic generation of code for embedded automotive applications offers a number of potential advantages over traditional methods. These include faster development, the avoidance of coding errors and avoiding inconsistencies with the design specification. However, the use of automatically generated code in production-intent safety-related systems requires at least the same standard of validation and verification. If code generation were perfect, one could validate only the design. However, it is impractical to require that the code generator must be validated for all possible input designs. Furthermore it must be assumed that the compiler and the hardware can also introduce faults.

In response to the question, “why do we want process improvement?”. This paper examines, from a software engineer's viewpoint some of the legal issues that are believed to affect the production and sale of automotive related software in the European Union and the constraints and requirements that this may place on the software quality process.

Quality assurance systems and ISO 9001 in particular have received a lot of attention in recent times, much of which is negative. Here we examine a more positive example and look at the role that ISO 9001 has played in embedded software development at Pi Technology. In this paper we address the following points. What the purpose of a quality system is or at least should be. Why we introduced a quality system and how we went about developing and implementing the system. We examine the pit falls we avoided and those we didn't and look at the positive benefits we believe we see from having a quality system in operation. We also generalise the lessons we have learnt to other quality systems such as CMM.