architecture. (Redistribution is not always possible because some applications tie the soft- ware to a specific ECU.) In a nutshell, the design problem for automotive applications consists of distributing a pool of functions over the target architecture to satisfy cost, safet , and real-time operating requirements. Because these applications are distributed, designers must accurately model the communication protocol. A by-product of the methodology described here is that designers can experi- ment with new protocol con- figurations.
Functional system analysis
System design partitioning
Software design specification
Calibration (lab car)
Communication subsystem testing
Software integration testing
Figure 1 illustrates the typ- ical “V” design flow for auto- motive distributed systems. The development process starts with the functional sys- tem analysis phase, in which the system designer develops a functional network (the overall system behavior). The system design partitioning phase determines the distribu- tion of functions in an architectural network. In the software design specification phase, the system designer defines algorithms for each functional component. The implementation phase maps a composition of functional com- ponents onto the target hardware. The upward part of the “V” design flow represents the verification process, including testing the implemented architecture’s software integra- tion, verifying the communication subsystem, and calibrating the system in the car. Figure 1. Typical “V” design flow for automotive distributed systems. The first-tier suppliers analyze the specifi- cations and negotiate the terms of the con- tract. The car manufacturer’s specifications might also include implementation require- ments, thus restricting the suppliers’ design space. For example, sometimes the contract lists particular microcontrollers to use. In addition, there is a growing trend for car man- ufacturers to use internally developed software instead of relying fully on first-tier suppliers. To ease integration, communication standards such as TTP and FlexRay provide clean semantics and guaranteed behavior. An OSEK-compliant operating system also eases integration.
The car manufacturer is responsible for overall functionalit , whereas the first-tier sup- pliers deliver control algorithms and hardware. The carmaker specifies system functionality on the basis of an overall analysis of desired car performance and features and decomposes this functionality into subsystem specifications sent to first-tier suppliers. Expert designers perform this decomposition, using their experience and sometimes prototypes (lab cars). They almost always write specifications informally in nat- ural language in a contract.
Without a rigorous design methodology that can deal with heterogeneit , specifications at different abstraction levels always cause problems. For first-tier suppliers, integrating other suppliers’ software modules is a severe problem, especially for hard real-time systems.
For safety-critical applications, the design of control algorithms that satisfy the func- tional requirements is a critical step for both car manufacturers and first-tier suppliers. Recently, manufacturers and first-tier suppli- ers have developed control algorithms using