CONTROL INFRASTRUCTURE FOR AUTOMOTIVE APPLICATIONS

Embodiments of the present disclosure relate to a control infrastructure and relates systems and devices for controlling automotive components associated with a first domain of automotive components. In accordance with one exemplary embodiment the system comprises a Performance Cluster chip, at least a first Peripheral Integrated Circuit (IC) chip, and a digital real-time communication link connecting the Performance Cluster chip and the first Peripheral IC chip. The Performance Cluster chip is configured to execute application specific software, which includes at least one control algorithm for controlling at least one automotive component of the first domain. The Performance Cluster chip includes a first clock generator circuit generating a master clock signal, and Peripheral IC chip includes a second clock generator circuit, which synchronizes to the master clock signal via the communication link to generate a slave clock signal for the Peripheral IC chip. The Peripheral IC chip includes at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator.

TECHNICAL FIELD

This disclosure relates to the field of engine control, in particular to the structure of the control system usually included in an engine control unit (ECU) and used to control the operation of an internal combustion engine.

BACKGROUND

Systems used for controlling the operation of internal combustion engines have become fairly complex and continuous further development is induced—inter alia—by changes in the legislation with regard to fuel consumption, exhaust gas emissions. Further aspects are the general need to reduce production costs, and the current use of different system architectures in the systems of the powertrain of an automobile

Today, the engine control of a gasoline combustion engine (Otto engine) today is either based on gasoline direct injection (GDI) or multi-port fuel injection (MPI). Other types of engines are Diesel engines or flexible fuel engines, which are able to combust ethanol, liquefied petroleum gas (LPG), compressed natural gas (CNG), etc. A vast variety of engine control systems and functions exist as well as many different types of sensors and actuators used to implement the engine control. The set-up of an engine control unit (ECU) may be specific for each automobile manufacturer. Many different sensors, actuators, and communication interfaces usually have to be supported be an ECU, which for the greater part developed and produced by car component suppliers and not by the automobile manufacturers. Today, almost all control functions needed for engine control are provided by semiconductor devices, which are mounted on a printed circuit board (PCB) included in the ECU. Examples for such semiconductor devices are application-specific micro controllers (μC) with volatile memory (RAM) and non-volatile memory (NVM), transceiver devices for communication between different PCBs or ECUs, devices providing power supply, so-called smart power devices (intelligent semiconductor switches), power devices (power semiconductor switches) and various interface devices to connect sensors. After many generations of ECUs and semiconductor devices a kind of optimum has been reached for a wide range engine set-ups. Nevertheless, as mentioned above, there is an ongoing pressure demanding further developments, improvements as well as cost reduction. In the semiconductor industry, the “classical” approach to increase efficiency and reduce costs has been shrinking the semiconductor structures to achieve a higher integration on the silicon. Further shrinking typically increases the costs for the semiconductor devices. This increase is usually over-compensated by the additional functionality due to the higher integration achieved by the shrinking. In some situations a point may be reached, where the mentioned over-compensation cannot be achieved anymore and the overall system costs may even increase.

SUMMARY

An electronic control unit for controlling an automotive component is described herein. In accordance with one exemplary embodiment the electronic control unit comprises a Performance Cluster chip with first circuitry integrated therein, a Peripheral Integrated Circuit (IC) chip with second circuitry integrated therein, a digital real-time communication link connecting the first circuitry and the second circuitry, and a printed circuit board (PCB) carrying the first and the Peripheral IC chip. The first circuitry includes a Central Processing Unit (CPU) that executes application specific software, which includes at least one control algorithm for controlling the automotive component. The first circuitry includes a first clock generator circuit generating a master clock signal for the first circuitry, and the second circuitry includes a second clock generator circuit, which synchronizes to the master clock signal via the communication link and generates a slave clock signal for the second circuitry. Furthermore, the second circuitry includes at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator.

Moreover, an automotive control system is described herein. In accordance with one exemplary embodiment, the automotive control system comprises at least a first master control unit, at least one first slave control unit, and a digital real-time communication link connecting the first master control unit with the first slave control unit. The first master control unit includes a Performance Cluster chip, which includes a Central Processing Unit (CPU) that executes application specific software, which includes at least one control algorithm for controlling at least one automotive component. The first slave control unit includes a Peripheral Integrated Circuit (IC) chip, which is associated with one of the at least one automotive component and which includes at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator. The Performance Cluster chip includes a first clock generator circuit generating a master clock signal, and the Peripheral IC includes a second clock generator circuit, which synchronizes to the master clock signal via the communication link to generate a slave clock signal for the first slave control unit.

Furthermore, a control system for controlling automotive components associated with a first domain of automotive components is described. In accordance with one exemplary embodiment the system comprises a Performance Cluster chip, at least a first Peripheral Integrated Circuit (IC) chip, and a digital real-time communication link connecting the Performance Cluster chip and the first Peripheral IC chip. The Performance Cluster chip is configured to execute application specific software, which includes at least one control algorithm for controlling at least one automotive component of the first domain. The Performance Cluster chip includes a first clock generator circuit generating a master clock signal, and Peripheral IC chip includes a second clock generator circuit, which synchronizes to the master clock signal via the communication link to generate a slave clock signal for the Peripheral IC chip. The Peripheral IC chip includes at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator.

DETAILED DESCRIPTION

As mentioned above, current implementations of engine control systems have reached a kind of optimum with regard to an efficient, qualitative and quantitative scalability and a continued increase of integration density does not seem to provide any further benefit. Increasing integration density may either even increase costs or is technically not feasible, due to e.g. power dissipation and power density. For example, further integration may lead to in-efficient implementation on chip and package level as most components are mixed signal ICs (integrated circuits) integrating digital (logic) electronic, analog electronic, as well as power electronic. The embodiment described herein therefore make use of an alternative approach, different from the classical approach of shrinking semiconductor structures and continuing to increase integration density.

The embodiments described herein are directed to an engine control unit (ECU). Nevertheless, the same concepts used in ECUs as described herein can also be applied to valid for a wide range other control systems used in an automobile, such as transmission control systems, hybrid- and electric powertrain control systems, chassis control systems including braking and vehicle stability control, safety control systems such as used in an airbag control unit, as well as advanced driver assistance systems.

FIG. 1illustrates an internal combustion engine and the basic functions, which are provided by modern engine management systems, by way of an exemplary schematic sketch showing a singly cylinder of an internal GDI (gasoline direct injection) combustion engine and some peripheral components. The construction of an internal combustion engine is generally known in the automotive field and thus only roughly summarized here.FIG. 1schematically shows a cross section through a cylinder block C, so one can see one piston P, which is coupled to the crankshaft via a piston rod R. An encoder wheel10is mounted to the crankshaft to allow incremental angular position measurement of the crank-shaft using a magnetic crankshaft sensor11(e.g. a Hall sensor or an inductive sensor). Today usually tooth-wheels, which have a pitch of 6 degrees, are commonly used as encoder wheels. The teeth are detected by as the crankshaft rotates and the crankshaft sensor11detects the teeth of the tooth wheel passing the crankshaft sensor11. Various sensor arrangements composed of an encoder wheel and a magnetic crankshaft sensor are known in the automotive field and thus not further discussed here in detail. It should be however noted, that other types of encoder wheels (e.g. magnetic multi-pole wheels) and other types of magnetic sensors could be used instead of the shown tooth wheel and Hall sensor. Although a gasoline engine is shown in the example ofFIG. 1, the embodiments described herein may also applied to other types of gasoline engines, diesel engines, flex fuel engines or any other types of internal combustion engines.

The intake valve21and the exhaust valve22of the cylinder are operated by the camshaft, wherein an angular position of the camshaft is detected by a camshaft sensor12. The fuel injector20is configured to inject a defined amount of fuel into the cylinder at a well-defined angular position of the crankshaft. In order to control the fuel injectors, an engine control unit (ECU) is employed, which is configured to precisely determine the angular position of the crankshaft based on the signals provided by the crankshaft sensor11and the camshaft sensor12. The deployed fuel-air mixture is ignited by the spark plug25at a specific time instant defined by an engine control unit (ECU). Besides the control of the injectors and the ignition, the ECU controls many other peripheral components used to operate the internal combustion engine. The peripheral components are, inter alia, the air intake, exhaust gas recirculation (EGR), the high pressure fuel pump21, the catalytic converter30, the secondary air injection32, the electronic throttle control ETC, etc. To accomplish all these control tasks, various sensors are used, such as, inter alia, the mentioned crankshaft and camshaft sensors11,12, a water temperature sensor41, Lambda sensors42,43, pedal position sensors (Pedal 1 and Pedal 2), intake air temperature sensor44, barometric air pressure sensor45or, optionally, an air mass flow sensor, knock sensor46, etc. All those peripheral components and sensors are as such known in the automotive field and are thus not further discussed here.

The output signals of the above-mentioned sensors, which are used to control the operation of the internal combustion engine, are supplied to the engine control unit (ECU), which processes the signal and provides drive signals for driving/controlling the above-mentioned actors (e.g. the fuel injectors20and the mentioned peripheral components). Modern ECUs are highly complex systems which provide a variety of different functions, which are summarized in the diagram ofFIG. 2. Accordingly, the ECU provides, inter alia, functions concerning the (air) intake system, the ignition system, the fuel system (including fuel injection), the exhaust system (including, e.g. the EGR), and accessory control (e.g. cooling fan, fuel pump, water pump, air condition control, etc.) The ECU further provides functions concerning torque control, functions concerning power supply, monitoring and diagnosis functions, as well as functions concerning communication with external devices (e.g. via a CAN bus). The function block labelled “safety functions” represents all functions necessary to comply with functional safety standards (defined, e.g. in ISO 26262 titled “Road vehicles—Functional safety”) and assure the required ASIL (automotive safety integrity level). For example, one safety function is the limitation of the intake air to limit the torque in case of a failure of other engine control functions. The function block labelled “security functions” relates to functions that ensure the integrity of data and access control (e.g. to prevent undesired engine tuning). The function blocks “μC control” and “system control” relate to functions for controlling the operation of the automotive micro-controller as well as of the overall ECU. The function block “operating data, program code” relates to software instructions and data processed by the automotive micro-controller.

In a common engine control unit (ECU) all the functions illustrated inFIG. 2are mainly provided using an application specific automotive micro controller, further referred to as microcontroller unit1(MCU) and one or more application specific ICs (ASICs)2,3,4,5, as well as some power semiconductor switches to drive specific actuators (e.g. the fuel injectors, the spark plugs, etc) also referred to as power stages6.FIG. 3Aillustrates the different ASICs of a today's ECU implementing the functions discussed above considering the present level of integration. The MCU1is configured to execute various software modules, which provide the core functions needed for engine control (i.e. the “intelligence” of the ECU), wherein the external (with regard to the MCU1) ASICs2,3,4basically provide auxiliary/supplementary functions such as power supply for the ECU and for connected sensors, electronic power switches, analog signal conditioning, fuel injector driver stages (GDI driver), etc. For years up to now, progress in the ECU development consisted in increasing integration density by shrinking the size of semiconductor structures. This “evolutionary” process of further development leads to more and more auxiliary functions being concentrated in one highly integrated ASIC, which is also referred to as System IC2. So when further developing the existing “traditional” ECU design approach of using one central MCU1and a highly integrated system IC2, almost all auxiliary/supplementary functions will be integrated in a single system IC2with only very few remaining functions being implemented using separate ASICs or other integrated circuit (IC) devices. So starting with a current ECU structure as shown inFIG. 3Athe logical next step (when following the mentioned evolutionary process of increasing integration density) could be to include, for example, the GDI driver IC3into the System IC2as shown inFIG. 3B. The “intelligence” including the all the signal processing required to accomplish the control and monitoring tasks provided by the ECU is concentrated in the MCU1. This signal processing includes, for example, the processing of the sensor signals and the generation of the control signal for driving/regulating various actors (e.g. valves, fuel injectors, pumps, etc.). As can be seen inFIGS. 3A and 3B, some power stages are integrated in the System IC2. In common ECU designs low and medium power stages are integrated into the System IC2, which is usually manufactured using a BCD (Bipolar-CMOS-DMOS) technology. High Power stages6are usually separate from the System IC to simplify heat dissipation. Theoretically, all functional components could be integrated in one System IC. However, some functions such as, for example, the electronic throttle control (ETC) better remains separate for safety reasons as mentioned above (e.g. in order to be able to comply with functional safety standards and required ASIL).

FIG. 4illustrates how the functions provided by an ECU and shown inFIG. 2are roughly distributed between the MCU1and the System IC2(and further ICs not integrated in the System IC). The previousFIG. 2illustrates the ECU purely by its functions, whereinFIG. 4shows the same functions asFIG. 2and is shaded with additional hatch patterns, which indicate how the individual functions are implemented. Thereby, a dotted pattern indicated analog electronic for analog signal processing (ASP), which includes analog sensor interfaces (e.g. amplifier, filters, etc.) as well as (pre-) driver circuits for driving the power stages that are connected to different actuators. The horizontally and vertically cross-hatched pattern represents (software) configurable hardware such as timers, counters, etc, which are used, for example, to trigger actuators or to process sensor signals. The slanted cross-hatched pattern represents transceivers and battery-related function blocks. Finally, the slanted hatched pattern represents application software (SW) executed by a processor core of the MCU1. As can be seen the MCU1includes the application software, configurable hardware as well as transceivers and battery-related functions, whereas the System IC2mainly includes analog circuitry for analog signal processing and (pre-) drivers for driving various actuators. The System IC also includes power stages for switching low-power and medium-power loads.

FIG. 5illustrates schematically the interconnections of MCU1, System IC2, further ICs4and5and a connector8on a printed circuit board (PCB). The further ICs4and5provide auxiliary/supplementary functions that are not (yet) integrated in the system IC2(see alsoFIG. 3B). It can be seen that the number of pins and interconnections is relatively high, which makes chip packages expensive and the signal routing on the PCB complex. The MCU1as well as the system IC have more than 150 pins, which have to be connected on the PCB. In the present example, the System IC2may include one or more transceiver circuits (TRX, physical layer circuitry, i.e. layers 1 and 2 of the OSI model), for example transceiver circuits for interfacing with CAN, LIN or FlexRay busses or—in future systems—even with an Ethernet network. The block6labelled FETs represents several discrete high power switches, which have not been integrated in the system IC2. The IC5implements the electronic throttle control (ETC), which is not integrated in the system IC2for safety reasons (see alsoFIG. 3B). In the current example, the GDI driver is integrated in the System IC2. However, the GDI driver may also be integrated in a separate IC (cf.FIG. 3A).

With the mentioned traditional concept of ECU design a kind of optimum has been reached with regard to on-board connectivity and the pin count of the packaged integrated circuits. A further increase of integration would entail a higher number of pins of the system IC and the MCU package, which makes the signal routing on the PCB board more complex, and thus the required space may even increase despite of the higher integration. Additionally or alternatively, the number of routing layers of the PCB would have to be increased, which may also have a negative effect on the overall system costs. Moreover, an increased integration density may entail a comparably high power density on the silicon chip, which generally entails a higher cooling requirements, such as the need for PCB materials with a higher glass-temperature and additional heat sinks. Finally, the positioning of the ICs on the PCB may be restricted du to thermal boundary conditions.

As the highly integrated system IC includes circuitry for processing analog and digital signals as well as power circuitry, the system IC usually is realized using a BCD (Bipolar-CMOS-DMOS) process technology, which is more costly as compared to using other process technologies such as, for example, high voltage CMOS (HV-CMOS) process technologies or pure power semiconductor manufacturing technologies such as SFET or MOSFET. To summarize the above, continuing the current approach of ECU design (which expedites miniaturization and highly integrated system ICs, in which many auxiliary/supplementary functions are concentrated) will hardly bring an additional benefit, particularly when high computing power and high-current switching are to combined in one chip. Due to the use of very application-specific components, the scalability of the present ECU design is low. The ECU design is inflexible with regard to changes, and changes in the system are difficult to implement and entail comparably high research and development expenses.

FIG. 6summarizes the above-described distribution of functions in ECUs, which are designed according to the existing approach described above. The microcontroller unit (MCU)1includes standard components (function blocks) such as CPUs (central processing units), volatile memory (e.g. SRAM) and non-volatile memory (NVM) as well as function blocks for direct memory access. The MCU1further includes function blocks for interfacing with sensors such as analog-to-digital converters (for digitizing analog sensor signals) and digital sensor interfaces like SENT (Single Edge Nibble Transmission) and PSI5 (Peripheral Sensor Interface 5). It further includes a general purpose timer (GPT) module, and communication interfaces for communicating with other electronic devices inside and outside the ECU. These communication interfaces may include the data layer for off-board communication like a CAN (Controller Area Network) interface, a LIN (Local Interconnect Network) interface, and a FlexRay interface, Ethernet, as well as serial interfaces for on-board connections such as SPI (Serial Peripheral Iinterface) and MSC (Microsecond Channel). As mentioned above, the core functions of the ECU, i.e. the functions necessary for controlling the engine, are implemented by software instructions executed by the CPUs.

A highly integrated system IC2(see alsoFIGS. 3B and 5) may include function blocks for providing power supply for the ECU, low-power and medium power semiconductor switches, monitoring and diagnosis functions, as well as pre-driver and driver stages for driving the fuel injectors, e.g. of a gasoline direct injection (GDI) engine, and various other actuators. A programmable sequencer may be used, e.g. to set a desired current-profile for the direct injection fuel injectors. The system IC2also includes communication interfaces such as MSC and SPI, basically for communicating with the MCU1. Furthermore, it contains the physical layer circuitry (layers 1 and 2 of the OSI model) of the off-board communication interfaces (e.g. Ethernet, FlexRay, CAN, etc.). High power semiconductor switches are typically integrated in separate power electronic devices. As mentioned, the MCU1is fabricated using a CMOS process, the system IC is fabricated using a BCD process, and the discrete high power device(s) is (are) usually fabricated in a SFET process. And as can also be seen fromFIG. 4, the System IC includes at least part of safety functions and power supply functions, as well as monitoring and diagnosis functions.

As mentioned above, further pursuing the traditional approach of miniaturization and concentrating most of the auxiliary/supplementary functions in one highly integrated system IC and using a highly application specific MCU seems to bring no or only little progress. The embodiments described below are designed using a novel concept, which breaks with the traditional approach of ECU design and the traditional distribution of functions among MCU1and System IC2. According the novel ECU design approach, the most of the functions, which are very specific to engine control are removed from the MCU, which is further referred to as Performance Cluster (PCL). The Performance Cluster is a high performance micro-controller that includes only a minimum of application-specific functions and easily could also be used in various other automotive applications. The previously described System IC is de-integrated into one or more ICs, further referred to as peripheral ICs (PICs), separate low-power and medium-power electronic switching devices (e.g. several MOSFETs included in one chip) and discrete semiconductor switches. The peripheral IC takes over the functions that have been removed from the MCU and are not further provided by the Performance Cluster.FIG. 7illustrates a diagram very similar to the diagram ofFIG. 4. The functions shown inFIG. 7are the same as shown inFIGS. 2 and 4. Also the realization of these functions indicated by the different hatch-patterns (analog signal processing, application software, configurable hardware, transceivers and battery related function blocks) are the same as shown inFIG. 4. However, an essential difference betweenFIG. 4(relating to the traditional ECU design approach) andFIG. 7(relating to the novel approach described herein) is the “dividing line” along which the implementation of the various functions is partitioned between Performance Cluster, at the one hand, and Peripheral IC and further ICs, at the other hand. Accordingly, most of the configurable hardware (including timers, counters, sequencers, etc.) as well as the sensor interfaces, which previously have been a part of the MCU are now moved to the Peripheral IC(s).

As can be seen inFIG. 8, one or more peripheral ICs2′ are employed instead of one highly, integrated system IC. All the low-, medium-, and high-power switches are realized as separate integrated or discrete power devices6and6′. In the present example, the functions of the peripheral IC2′ is distributed by two ICs, the base peripheral IC2aand a GDI peripheral IC2b. However, both parts2a,2bcould also be integrated in one IC2′. As a consequence of the de-integration suggested herein, the peripheral ICs2′ do not need to provide power electronic functions and thus may be fabricated using a common HV-CMOS process instead of a more complex BCD process. The sensor interfaces (e.g. ADCs, SENT and PSI5 interface) have been removed from the MCU1, which is now the Performance Cluster1′. Those sensor interfaces are now included in the peripheral ICs2′, in the preset example in base peripheral IC2a. The second, GDI peripheral IC2bshown inFIG. 8includes function blocks concerning the driving, monitoring and control of, for example, the fuel injectors for direct injection (DI) engines. In addition to the control of GDI injector valves, the peripheral IC2bor a similar peripheral IC may be used to drive, monitor and control solenoids for other purposes, such for intake and exhaust valve control as well as current-controlled proportional valves.

The above-described approach (i.e. to separate base peripheral and GDI peripheral IC) may be chosen to stay in the sweet spot with regard to the semiconductor technology used to produce those ICs. The direct injection function usually uses a high voltage technology for typically 90V (e.g. HV-CMOS or BCD), whereas a 60V technology may be sufficient for other components. The GDI peripheral IC2band the base peripheral IC2a(see alsoFIG. 15A) may communicate with a dedicated High Speed Seral Link (HSSL), which—in the traditional ECU design—can be employed for (a time-based and time-triggered) communication between the MCU1and an external GDI driver (seeFIG. 3a, GDI driver3a). Only a few components from the traditional ECU design are realized separately (ICs4,5, and TRX), in particular ICs, which implement safety-relevant functions, e.g. in case of the safety supply for some safety relevant ICs. In the present example ofFIG. 8these are functional blocks providing the electronic throttle control (ETC) and some other safety functions. Also those components, which are in direct contact with the automotive battery (the on-board power supply), may have to comply with rather strict requirements concerning EMC (electromagnetic compatibility). In many applications separate chips manufactured in BCD technology may be best suited to comply with these requirements. Nevertheless, most of the (low-power and medium-power) power stages, which are integrated in the system IC in the traditional ECU design, are de-integrated and realized as separate power stages6′ (using e.g. FINFET or RCB technology), and thus the need for a BCD technology is avoided for the peripheral ICs2′.

As the application specific functions blocks needed for the engine control, in particular the mentioned sensor interfaces, have been removed from the microcontroller unit, a more generic microcontroller can be used. Flexibility and scalability are improved. The removal of the power semiconductor switches from the system IC helps to overcome limitations with regard to heat dissipation, which exist in the system IC according to the traditional ECU design. Generally, this re-partitioning of functional blocks (i.e. removal of sensor interfaces from the microcontroller, removing power electronics from the system IC) can reduce the overall complexity of the ECU and thus reduce costs for production and testing as well as time-to market are reduced. The size of the packages can be reduced by de-integration, which can reduce the space requirements on the PCB of the ICs. To illustrate this effect it is noted, that a QFP (Quad Flat Package) with 1440 pins needs almost twice the area than two QFPs with 64 pins each when using the same pin pitch.

TheFIGS. 9A and 9Billustrates schematically the interconnections of Performance Cluster1′, Peripheral IC2′, low-power and medium-power power stages6′, high-power semiconductor switches6, as well as further ICs4, TRX (which are separate for safety reasons as discussed above) as well as a connector8on a printed circuit board (PCB). InFIG. 9Athe single peripheral IC2′ includes all the functions described with reference toFIG. 8including the GDI driver functions, whereas the GDI driver functions are in a separate peripheral IC2bin the case ofFIG. 9B. The power supply (“safety supply”) is implemented in a separate chip in order to maintain a safe power supply even in case other circuit components fail.

As mentioned above, the Performance Cluster1′ is now optimized with regard to computing power (for executing application software) and all the application specific peripheral interfaces (e.g. sensor interfaces such as SENT, PSI5, and analog interfaces) are integrated in one or more peripheral ICs (IC2′ or ICs2a,2bin case ofFIG. 9B). As the sensor interfaces are in the peripheral IC2′, the sensor information is at least partly processed in the peripheral IC2′. Sensor information (especially from crankshaft sensor11and camshaft sensor12, which is crucial for engine control), which is needed in the Performance Cluster1′ as input for the monitoring and control algorithms (in general referred to as application software) executed by the Performance Cluster1′ is communicated from the peripheral IC2′ to the Performance Cluster1′ via a data bus7. Similarly, the output data that is generated by the control algorithms executed by the Performance Cluster1′ and needed in the peripheral IC to drive actuators such as the fuel injectors (via power switches in IC4b) is communicated back to the peripheral IC2avia the data bus7. Accordingly, the data bus7is a bidirectional bus. As mentioned above, the control of the actuators such as the fuel injectors is very critical and depends on the angular position of the crankshaft. Thus time and angle have to be well synchronized in the Performance Cluster1′ as well as in the peripheral IC2′, and, therefore, the high-speed bus has to be realtime capable and allow for a comparably fast data transmission. In the present embodiments a bidirectional real-time capable high-speed serial bus is used as data bus7to connect the Performance Cluster1′ and the peripheral IC2a. With regard to timing, the Performance Cluster is the master device that is connected to a crystal oscillator13(XTAL), which provides a time base. As a consequence Performance Cluster1′ and the Peripheral IC2′ “see” the same absolute time. However, as will be discussed in more detail later, even a very fast data bus7is not able to communicate the sensed angle information directly to the Performance Cluster1′ in real time. Thus a specific mechanism will be necessary to synchronize angle information between the Peripheral IC2′ and the Performance Cluster1′, wherein the peripheral IC2′ is the master device with regard to angle measurement and angle synchronization information is regularly transmitted regularly from the peripheral IC2′ to the Performance Cluster regularly.

The de-integration of the sensor interfaces from the MCU has some significant consequences on the operation of the whole engine control unit (ECU), in particular with regard to the time/angle synchronization. In ECUs, which are designed in accordance with the traditional approach (seeFIGS. 3 to 6), the MCU generates—based on a crystal oscillator—a clock signal, which is used as a time basis of the overall system (i.e. the ECU). That is, the MCU is the master device with regard to timing. The MCU combines the clock signal with the angle information that is provided by the crankshaft sensor11and the camshaft sensor12(seeFIGS. 1 and 10) of the internal combustion engine. A complex angle estimation circuit (implemented by dedicated hardware, which may be software-configurable) accomplishes the time/angle synchronization with high precision by the prediction, interpolation and correction of the angle and time values regularly provided by the angular position sensor(s). Based on this time/angle synchronization, all control operations to be performed at the engine are calculated by the CPU included in the MCU. These control operations are triggered instantly by the MCU based on the clock signal and the mentioned time/angle synchronization. The mentioned time/angle synchronization is as such known and, for example, explained in the publication Leteinturier, P. and Benning, J., “Enhanced Engine Position Acquisition&Treatment,” SAE Technical Paper1999-01-0203, 1999, which is hereby incorporated by reference in its entirety. The mentioned angular position sensor(s) provide signal(s), that are indicative of a specific angular position value (e.g. of the crank-shaft) at a specific time instant. An angular position sensor may, for example, generate a sensor signal composed of a sequence of pulses, wherein the time instant, at which a pulse occurs (e.g. the time instant of a rising edge of a pulse), indicates a specific increment of the angular position (e.g. 6°). That is, the pulses occur periodically with a specific periodicity (angle-period) of e.g. 6°, wherein the time-period between two subsequent pulses varies dependent on the angular velocity of the crank-shaft.

When using the novel ECU design approach described herein (seeFIGS. 7 to 10), the above described time/angle synchronization cannot anymore be done in the MCU, now referred to as Performance Cluster. As shown inFIG. 10, the reason for this is that—different from the traditional design—the sensor information from the crankshaft sensor11and the camshaft sensor12is not directly available in the Performance Cluster but primarily only in the peripheral IC. However, the angle estimation circuit cannot simply be moved to the peripheral IC2′ (or2ain case ofFIG. 9B) because the estimated time and angle values determined by the angle estimation circuit cannot be transmitted to the Performance Cluster1′ via the data bus7fast enough. In accordance with the novel design approach described herein the angle estimation circuit is distributed among the Performance Cluster1′ and the peripheral IC2′. Accordingly, a master angle estimation circuit is provided in the peripheral IC2′ and a slave angle estimation circuit is provided in the Performance Cluster1′, wherein the master angle estimation circuit in the peripheral IC regularly (in each angle-period) transmits predicted (by extrapolation) a starting angle Â (e.g. in degree) and a corresponding predicted time instant T̂ for the next angle-period (e.g. defined by the tooth pitch of the tooth-wheel, typically 6°), a predicted angular velocity V̂ and angular/time delay values, which are used as correction values by the slave angle estimation circuit in the Performance Cluster (see alsoFIGS. 12A-12Cand corresponding explanations below). Thereby the pair of predicted angle Â and time T̂ includes the acceleration information determined during the preceding angle-period. Based on the information received from the master angle estimation circuit, the slave angle estimation circuit in the Performance Cluster can separately interpolate angular values (so-called micro-ticks, μTi) as described below in more detail, and the Performance Cluster may then process these interpolated time and angle values (micro-ticks) in a conventional manner using know engine control algorithms executed by the CPU of the Performance Cluster.

FIG. 11illustrates a simplified example of an ECU composed of, inter alia, first circuitry, which implements the Performance Cluster1′ (performance cluster, seeFIG. 10), and second circuitry, which includes at least one peripheral IC2′. As mentioned above, the Performance Cluster1′ is the master device with regard to timing, whereas the peripheral IC2′ is the slave device. Accordingly, the Performance Cluster1′ is coupled with an oscillator (e.g. a crystal oscillator XTAL) that provides a stable reference clock signal CLKRfor the Performance Cluster1′. The Performance Cluster1′ includes a clock generation circuit103that generates a mater clock signal CLKM, which is provided to all clocked circuitry on the Performance Cluster1′ such as, e.g., the CPU110. The clock generation circuit103usually includes a phase locked loop (PLL), which may be implemented in any conventional manner. The Performance Cluster1′ further includes a bus interface105for the mentioned bidirectional real-time high-speed serial bus7, which allows real-time data exchange between peripheral IC2′ and the Performance Cluster1′ (see alsoFIG. 10). The peripheral IC2′ includes a corresponding bus interface205connected to the bidirectional real-time high-speed serial bus7.

All clock signal in the Performance Cluster1′ are based on the master clock signal CLKMand thus in a fixed phase relation to the reference clock signal CLKRprovided by the crystal oscillator13. That is, the bus clock signal used to clock the data transmission across the data bus7is also synchronized with the master clock signal CLKMand thus with the reference clock signal CLKR. In order to synchronize the operation of the circuitry in the peripheral IC with the master clock signal in the Performance Cluster1′, the peripheral IC2′ also includes a clock generation circuit203, which uses the bus clock of the serial bus7as a reference to generate a slave clock signal CLKSin the peripheral IC2′. The clock generation circuit203may also include a PLL (e.g. a digital PLL, DPLL) and operate in a similar manner as the clock generation circuit103of the Performance Cluster1′. As a consequence, the slave clock signal CLKSin the peripheral IC2′ is synchronized (via the bus clock) with the master clock signal CLKMin the Performance Cluster1′, which ensures that the peripheral IC2′ operates substantially in synchronization with the Performance Cluster1′.

As explained above, the slave clock signal CLKS, which is provided to all clocked circuitry of the peripheral IC2′, is locked to the master clock signal CLKMof the Performance Cluster1′. While the Performance Cluster1′ is the master device with regard to timing, the peripheral IC2′ is the master device with regard to the angle, i.e. the angular position and velocity of the crank-shaft. Accordingly, the peripheral IC2′ includes a master angle estimation circuit201whereas the Performance Cluster1′ includes a respective slave angle estimation circuit101. The master angle estimation circuit201receives the angle information provided by the externally connected angle sensors, i.e. by the crank-shaft sensor11and the camshaft sensor12. The angle sensors may be connected to the peripheral IC2′ in any conventional manner. In the present example, the peripheral IC2′ includes a SENT interface220to receive angle information from the sensors11,12.

The angle sensors11,12usually do not provide the angular resolution, which is needed to accomplish the control tasks implemented in the ECU with sufficient quality. In today's engine control systems the crankshaft-sensor11generates one pulse each 6 degree (corresponds to the mentioned angle-period). With an angle period of 6 degrees a full revolution has 60 angle-periods, wherein usually 58 pulses are generated instead of 60 pulses per revolution, as two pulses are omitted in order to detect the zero position of the encoder wheel coupled to the crankshaft. However, a resolution of 6 degrees is far too low to precisely control the engine operation, in particular to control the operation of the fuel injectors (seeFIG. 1). Therefore, the master estimation circuit201is configured to generate interpolated pulses—so-called micro-ticks (μTi)—between the pulses provided by the crank-shaft sensor11. This μTi generation is as such known (see, e.g., the above mentioned publicationSAE Technical Paper1999-01-0203) and therefore not explained here in detail. In essence, a digital phase locked loop (DPLL) is used to generate the micro-ticks.

The following explanations refer to the diagrams inFIGS. 12A to 12C, whereinFIG. 12Arelates to the case, in which the angular speed is constant (angular acceleration is zero),FIG. 12Brelates to the case, in which the angular speed decreases (angular acceleration is negative) andFIG. 12Crelates to the case, in which the angular speed increases (angular acceleration is positive). However, before explainingFIGS. 12A-12Cin more detail, some general considerations follow. In General, the μTi generation can be seen as a kind of angle prediction or estimation, which is only exact when the engine is in a steady state (i.e. has a constant angular velocity). In case the angular velocity is not constant (e.g. at positive or negative angular acceleration) it is, however, possible to predict (estimate) the time instant, at which the next 6° sensor pulse will occur, or, in other words, to predict the angular velocity for each angle-period. The time instant of the next pulse of the crankshaft sensor (or the angular velocity during an upcoming angle-period) can be predicted based on the current velocity and acceleration value obtained based on the sensor pulses (received after each 6 degree of rotation), which have been already detected. In essence, when a pulse from the crankshaft sensor is received, the duration of the period to the next occurrence of a pulse (e.g. 6 degrees later) is estimated by extrapolation based on the current angular velocity and acceleration and the μTi generation can be tuned accordingly. That is, the pulse-frequency of the μTi is set based on the estimated angular velocity. Based on the sensor pitch (e.g. 6 degrees) and this predicted duration between a current sensor pulse and the subsequent sensor pulse (i.e. 6 degrees later) an equivalent angular velocity can be determined (predicted duration divided by pitch) for the current period. If the acceleration or deceleration of the engine changes within this predicted period, the angular position indicated by the (counted) number of μTi and the angular position indicated by the actual pulse received from the crankshaft sensor do not match and the angular position indicated by the μTi counter has to be corrected. If the angular velocity of the engine has increased during the predicted period, the μTi counter has counted too slow and thus cannot complete the desired number N of μTi until the end of the actual period (which is shorter than the predicted period) and some μTi are “lost”. Accordingly, the speed of the μTi counter (representing the measured and interpolated angular crankshaft position) is increased for the next period to compensate for the lost μTi. If the angular velocity of the engine has decreased during the predicted period, the μTi counter has counted too fast and thus generates the desired number N of μTi before the actual end of the period (which is longer than the predicted period) is reached. Accordingly, the μTi counter (representing the measured and interpolated angular crankshaft position) is paused until the end of the actual period to correct the overestimated angular position.

In four-stroke internal combustion engines, the angular position measurement may be done in intervals of 720 degrees, which corresponds to two full revolutions of the crank-shaft. In order to distinguish between the first and the second revolution of a 720 degree period, the information obtained by the camshaft sensor12is used, as the camshaft only performs one revolution during one 720 degree period of the crankshaft. That is, the crankshaft rotates twice as fast as the camshaft while both are coupled via a cam chain or a cam belt. The number N of μTi generated within one (e.g. 6 degree) period of the crank-shaft sensor may depend on the control algorithms used in the ECU. An exemplary number of N=64 μTi per period of 6 degrees would result in a theoretic resolution of 0.09375 degrees.

In view of the general considerations above, one specific example is explained in more detail with reference toFIG. 12A, which illustrates a case, in which the angular velocity is constant and, therefore, the angular velocity for an upcoming angle-period can be well predicted based on the velocity of the previous period. In the present example, it is assumed that the crank-shaft sensor (seeFIG. 1, sensor11) uses an encoder wheel that has a pitch of 6 degrees. That is, the sensor11generates a sensor pulse after each angle increment of 6 degrees, so that 60 pulses are generated during one full revolution of the crankshaft. In fact, only 58 pulses are generates in many application because two pulses are left out (producing a “gap”) to enable zero-point detection.FIG. 12Aincludes twelve timing diagrams. The first (top) diagram illustrates the pulse chain generated by the crank-shaft sensor11. The individual pulses are denoted as Pn, wherein n is an index running from 0 to 59 (in case of a 6° pitch). The temporal spacing of the pulses Pn-6, Pn-5, Pn-4, etc. depends on the angular velocity, i.e. an angle of 6° corresponds to a time of 6°/V, wherein V is the angular velocity in degrees per second. The second timing diagram illustrates the sensor signal (pulse chain) using a magnified time scale.

In any practical implementation, the real sensor signal is not perfect and subject to errors. As shown in the second timing diagram, the rising and falling edges of the individual pulses have significant rise and fall times that may vary due to noise and tolerances of the electronic components used in the sensor electronics. Furthermore, the angular spacing between two neighboring pulses (e.g. Pn-4and Pn-3) is not necessarily precisely 6 degrees but may vary due to mechanical (geometric) errors of the encoder wheel. Further sources of errors may be noise, signal propagation times, the mentioned tolerances of electronic components in the sensor electronics, etc. Due to these errors the pulses may exhibit a jitter dJITwith respect to the—theoretic—ideal sensor signal shown in the third timing diagram ofFIG. 12A.

The mentioned errors may be (at least partially) corrected by common methods, which are as such known and thus not discussed in details therein. For example, the mechanical tolerances of the encoder wheel (i.e. deviations from the ideal 6° pitch) may be corrected using calibration data stored in a memory. Various methods to compensate the error (the jitter) may be applied, such as static or temporal calibration data from memory but also dynamic correction using e.g. extrapolation and/or interpolation methods. Generally, the correction process is completed within a time span dCORRfollowing a sensor pulse generated by the crank-shaft sensor. The fourth diagram, illustrates the corrected sensor signal, whose pulses indicate an angle increment of exact 6° (if neglecting remaining errors that could not be corrected). In the present example, the corrected sensor pulse occurs exactly at the end of the time span dCORR. However, it should be noted that the time span dCORRdenotes a time window, throughout which the rising edge of the corrected pulse can occur at any time (dependent on the actual correction value). Therefore, the time span dCORRcan also be regarded as a maximum delay between the actual sensor signal (second timing diagram ofFIG. 12A) and the corrected sensor signal (fourth diagram ofFIG. 12A). The further synchronization process between the master angle estimation unit201and the slave angle estimation unit101(seeFIG. 11) is based on that corrected sensor signal.

The rising edge of the corrected sensor signal triggers a counter (μTi counter) which generates a μTi in each counter cycle. In the present example the counter starts at a predefined value (e.g. 15) and counts down to zero, to subdivide one 6 degree period into 16 micro-ticks (μTi). In this example, which is illustrated in the fifth diagram ofFIG. 12A, one μTi would correspond to 0.375 degrees. The counter clock, which determines the counting speed of the μTi counter may be adjusted in each cycle based on an estimated angular velocity value VA. This estimation may be based on the pitch of the encoder wheel (e.g. 6°) and the temporal distance between the current pulse (e.g. Pn-4) and the preceding pulse (e.g. Pn-5). In the present case of a steady state (no acceleration) this estimation is comparably precise and the time, which the μTi counter needs to count down to zero, exactly fits into the time span between the current pulse (e.g. Pn-4) and the subsequent pulse (e.g. Pn-3). The resulting μTi signal is illustrated in the sixth timing diagram ofFIG. 12A.

The mechanism for μTi generation as explained above is essentially performed in the master angle estimation unit201. To allow a similar μTi generation at the Performance Cluster's side (i.e. in the slave angle estimation unit101) angle and velocity information is regularly transmitted from the master angle estimation unit201to the slave angle estimation unit101via the real-time capable serial bus7. In the present example, an estimated triple Â, T̂, V̂ (including an estimated angle value Â, a corresponding time value T̂ and a corresponding angular velocity value V̂) is transmitted to the he slave angle estimation unit101via the real-time capable serial bus7at the beginning of each 6° pulse period P. In the slave angle estimation unit101a new period will begin at the angular position Â at time instant T̂, wherein the μTi counter clock is set based on the estimated angular velocity value V̂. The time instant T̂ is calculated based on the current absolute time and a maximum data transmission time (dDTD), which it may take to transmit the angle and velocity information (i.e. Â, T̂, V̂) to the slave angle estimation unit101via the real-time capable serial bus7. The data transmission time dDTDis illustrated in the seventh diagram ofFIG. 12A. At time instant T̂ (corresponding to an angle Â) a new period is triggered in the slave angle estimation unit101and the clock rate for the μTi counter is adjusted based on the estimated angular velocity V̂. Theoretically, the sensor signal could be reproduced in the slave angle estimation unit101(See eighth timing diagram ofFIG. 12A), wherein a rising edge of the reproduced sensor signal occurs at time T̂. However, this signal is only included inFIG. 12Afor illustrative purposes and is not needed in the current embodiment. The ninth and tenth timing diagram show the count-down of the μTi counter and the corresponding sequence of μTi in the slave angle estimation unit, which may be implemented in the same way as in the master angle estimation unit. The time lag of the μTi sequence of in the slave angle estimation unit (tenth timing diagram ofFIG. 12A) with respect to the μTi sequence of in the master angle estimation unit (fifth timing diagram ofFIG. 12A) corresponds to the maximum transmission time delay dDTD. This time lag is, however, considered in the estimation of the angle Â which is transmitted via the serial bus7.

The timing diagrams ofFIG. 12Billustrate the μTi generation mechanism in a situation, in which the engine decelerates (negative acceleration) and the pulses Pnof the sensor signal are received later than in the steady-state case (no acceleration). That is, the duration of the pulses in the sensor signal (see first and second timing diagram onFIG. 12B) increases during the deceleration phase. The fourth timing diagram ofFIG. 12Bshows the ideal sensor signal with an ideal 6° pitch (without errors). As explained before with reference toFIG. 12A, the real sensor signal (second timing diagram ofFIG. 12B) may exhibit some jitter dJIT, which can be corrected within a time window dCORR(see fifth timing diagram ofFIG. 12B). In this regard, reference is also made to the steady state example discussed with reference toFIG. 12A. As mentioned above, the duration of the sensor pulses increases and thus the rising edge of the pulse Pn-3lags behind by a time lag dERRas compared with the steady state case (see third timing diagram ofFIG. 12B).

The μTi generation is done the same way as in the previously discussed steady state case. However, because the clock rate of the μTi counter is set based on an estimated velocity, which is basically an extrapolation of the average velocity during the preceding 6° period, the μTi counter counts too fast (as the engine decelerates) and reaches zero at a time, which is about dERRbefore the next pulse of the sensor signal. As each 6° period is subdivided into an equal number of μTi the counter has to be paused before starting a new “count-down” at the rising edge of the next pulse of the sensor signal (see the sixth and seventh timing diagram ofFIG. 12B).

Analogously to the steady-state case, an estimated triple Â, T̂, V̂ is transmitted from the master angle estimation unit201to the he slave angle estimation unit101via the real-time capable serial bus7at the beginning of each 6° pulse period Pn. Based on the transmitted information, the sensor signal could be reconstructed at the Performance Cluster's side (see eighth and ninth timing diagram ofFIG. 12B). The μTi generation is done as explained before in connection with the steady state case, wherein the clock rate of the μTi counter is set in accordance with the transmitted angular velocity value V̂, which is an estimated value that is always too high during a deceleration phase. For this reason the same situation occurs as in the master angle estimation device201and the counter has to be paused until the next count-down starts in the subsequent period (see tenth and eleventh timing diagram ofFIG. 12B).

The timing diagrams ofFIG. 12Cillustrate the μTi generation mechanism in a situation, in which the engine accelerates (positive acceleration) and the pulses Pnof the sensor signal are received earlier than in the steady-state case (no acceleration). That is, the duration of the pulses in the sensor signal (see first and second timing diagram onFIG. 12C) decreases during the acceleration phase. The fourth timing diagram ofFIG. 12Cshows the ideal sensor signal with an ideal 6° pitch (without errors). As explained before with regard to the steady-state case (FIG. 12A), the real sensor signal (second timing diagram ofFIG. 12C) may exhibit some jitter dJIT, which can be corrected within a time window dCORR(see fifth timing diagram ofFIG. 12C). As mentioned above, the duration of the sensor pulses decreases and thus the rising edge of the pulse Pn-3is early by a time dERRas compared with the steady state case (see third timing diagram ofFIG. 12C).

The μTi generation is done the same way as in the previously discussed steady state case. However, because the clock rate of the μTi counter is set based on the estimated velocity, which is basically an extrapolation of the average velocity during the preceding 6° period, the μTi counter counts too slow (as the engine accelerates) and does not reach zero before the next pulse of the sensor signal is received from the sensor11. Thus, some μTi are “missing” at the end of the current 6° period. As each period is subdivided into an equal number of μTi the clock rate of the μTi counter has to be temporarily increased to catch up for the missing μTi. When the counter has reached zero a new countdown follows immediately as shown in the sixth and seventh timing diagram ofFIG. 12C.

Again, an estimated triple Â, T̂, V̂ is transmitted from the master angle estimation unit201to the he slave angle estimation unit101via the real-time capable serial bus7at the beginning of each 6° pulse period Pnas discussed before with regard to the steady-state case. Based on the transmitted information, the sensor signal could be reconstructed at the Performance Cluster's side (see eighth and ninth timing diagram ofFIG. 12B). The μTi generation is done as explained before in connection with the steady state case, wherein the clock rate of the μTi counter is set in accordance with the transmitted angular velocity value V̂, which is an estimated value that is always too low during a acceleration phase. For this reason the same situation occurs as in the master angle estimation device201and the clock rate of the μTi counter has to be temporarily increased to catch up for missing as explained above for the master angle estimation unit (see tenth and eleventh timing diagram ofFIG. 12C).

The following description again refers toFIG. 11. As discussed above in detail, the high resolution angular position information obtained by the μTi cannot be shared with the Performance Cluster1′ via the data bus7. For this reason, in the traditional ECU design, the sensors have been connected to Performance Cluster and the micro-tick generation has been performed by the Performance Cluster, which then used the μTi in the control algorithms. However, according to the novel ECU design approach described herein, a separate slave angle estimation circuit101is provided in the Performance Cluster1′, which operates in a similar manner as the master angle estimation circuit201. However, instead of information from the crankshaft and camshaft sensors11,12, the slave angle estimation circuit101uses time, angle and velocity values Â T̂, V̂ received from the master angle estimation circuit201. Both, the clocks CLKMand CLKSof Performance Cluster1′ and, respectively, peripheral IC2′ are synchronized and thus Performance Cluster1′ and peripheral IC2′ “see” the same absolute time. Master and slave angle estimation circuits201,101are regularly (e.g. once in each 6° period) synchronized with regard to angle information using the synchronization circuits206,106in the peripheral IC2′ and the Performance Cluster1′, respectively, which are coupled by the bidirectional real-time data bus7.

FIG. 13illustrates an exemplary embodiment of an ECU that is designed according to the novel approach described above, whereinFIG. 13Aillustrates the peripheral IC andFIG. 13Billustrates the Performance Cluster in more detail as compared toFIG. 11. As mentioned above, the sensors used for the engine control (e.g. crankshaft sensor11, camshaft sensor12, etc.) are connected to the peripheral IC2′, which, in the present example, also includes the functions needed for the gasoline direct injection. As already discussed with reference toFIG. 11, the peripheral IC2′ includes a bus interface205to allow communication with the Performance Cluster1′ via the bidirectional serial bus7. All time and angle critical information is transmitted via the bus7as discussed above. Analysis show that that the bus should be capable to transmit data at transmission rate of about 70 Mbit/s (duplex). For example, the bus may use LVDS (low-voltage differential signaling) for signal transmission. The DPLL (digital PLL)203generates the slave clock signal CLKS, which is phase locked to the master clock signal CLKMas discussed above with reference toFIG. 11.

The master angle estimation circuit201is illustrated in more detail inFIG. 13A. Accordingly, the crankshaft sensor11and the camshaft sensor10are connected to SENT interfaces220and223. In essence one pulse is generated at a specific angular pitch, e.g. 6 degrees, for the crankshaft sensor10, and 720 degrees for the camshaft sensor12(as the camshaft rotates at half the speed than the crankshaft). The functional blocks221and224perform the period measurement including error correction as discussed above with reference toFIG. 12. The functional block222performs the mentioned zero-point detection by detecting the gap of the encoder wheel (as mentioned two 6° periods may be left out to produce one 18° period each revolution). The master angle estimation circuit201includes a modulus 360° counter2015and a modulus 720° counter2016to cover all four strokes of the combustion engine (intake, compression, explosion, exhaust). The prediction unit2017is connected downstream to the modulus 720° counter2016and is configured to predict (calculate by extrapolation) the average angular velocity V̂ during the current period, which is used to set the clock rate of the μTi counter as discussed before with reference toFIGS. 12A-C. The micro-tick generator2018includes the μTi counter that generates the μTi based on the predicted velocity value V̂ for the current period. The functional block2020performs initiates the pausing of the μTi counter as discussed with reference toFIG. 12Band the temporary increase of the counter clock rate as discussed with reference toFIG. 12Cto account for deceleration and acceleration of the engine. The functional block2019labelled “Consistency” is only needed in the master angle estimation circuit, and is configured to check whether the pulses received from the sensor (e.g. with a pitch of 6°) occur with a given realistic time window. If a pulse would occur outside this time window, the pulse is not plausible in view of the mechanical constraints of the engine (inertia) and can be disregarded. Dependent on the actual implementation of the crankshaft sensor erroneous pulses may be generated due to noise and other disturbances.

The synchronization unit206receives the values Â, T̂ and V̂ (e.g. from the prediction unit2017) and encodes the values into a data frame that can be transmitted via the serial bus7. The functional block207labelled “Low Level Driver Software” includes firmware which allows for receiving and transmitting data from and to the bus7. The firmware is also configured to forward further sensor data (e.g. from the driver and engine sensors connected to the Peripheral IC) received by sensor interface210to the Performance Cluster, where the sensor data can be processed by the application software. The firmware is also configured to receive control commands concerning fuel injection sent to the Peripheral IC via the serial bus. The control commands may include, for example, information about the subsequent injection. To prepare the injection, the state machine208(labelled “event prediction”) is programmed (configured) by the firmware and then triggers the injector—based on the μTi sequence—at a desired angular position of the crankshaft. The Peripheral IC may also include a driver stage209which is configured to generate driver signals (e.g. gate voltage signals) for the externally connected power stage5(e.g. power MOSFETs), which are coupled to the solenoid of an injector20to switch the injector current on and off. The functional block211labelled “Measurement” may be configured to receive feedback signals from the power stage5and/or the injector20and forward the measured information (e.g. the injector current during the latest injection) to the application software executed in the Performance Cluster (via bus7) and/or the driver stage209.

InFIG. 13B, the slave angle estimation circuit101also includes a prediction unit1017and a micro-tick generator1018. However, the prediction unit1017regularly receives time, angle and angular velocity values T̂, Â and V̂ from the master angle estimation circuit201via the data bus7instead from the sensors (crankshaft sensor11and camshaft sensor12, seeFIG. 1), and triggers the count-downs of the μTi counter (seeFIG. 12A-C). The task of the synchronization unit107is basically the decoding of the data frame including the values T̂, Â, and V̂. The functional blocks1018and1020have essentially the same purpose than the corresponding functional block2018and2020in the peripheral IC's side. That is the functional block1018controls the temporary pause of the μTi counter (seeFIG. 12B) in case of deceleration if the engine and temporary increase of the μTi counter clock rate (seeFIG. 12C) in case of acceleration.

The engine control functions as such (core functions) are implemented in software (application software) and executed by the CPU107using appropriate software instructions. Particular with regard to fuel injection, the CPU107calculates based on various input data the next “event” such as the amount of fuel for the next injection and the angular position of the engine, at which the event is to be trigged. The angular position, at which an event is to be triggered may be communicated to the event prediction unit133, which receives the μTi and initiates a respective actuation command at the command at the correct angular position. The event prediction unit133is basically the same as the event prediction unit233in the Peripheral IC and may be implemented as a finite state machine. A similar event is the ignition. The calculated information is forwarded to the function block133labeled “event prediction”, which is configured to trigger the desired events (e.g. the actuation of a fuel injector) determined by the CPU107at the correct angular position based on the micro-ticks. The actuation command is then transmitted to the peripheral IC2′ via the serial bus7and further processed in the peripheral IC.

FIG. 14illustrates three different examples of combining one or more peripheral ICs with one (single) Performance Cluster in one ECU. As illustrated before inFIGS. 9A and 9Bthe peripheral IC2′ may be—dependent on the application—split into separate ICs2A and2B (seeFIG. 9B). In the following discussion, a single peripheral IC2′ is assumed. However, it is understood that this peripheral IC2′ could be easily replaced by two or even more peripheral ICs.FIG. 14Aillustrates the case which has been discussed above, in which one Performance Cluster1′ is connected to at least one peripheral IC2′ in an ECU. In the Performance Cluster1′ the computation power is concentrated, wherein the sensors, particularly the angle sensors, are connected to the peripheral IC2′. Performance Cluster1′ and peripheral IC2′ communicate (only) via a bidirectional high-speed real-time capable bus7. The peripheral IC2′ may include the direct injection driver circuits (which may also be separate). For actually actuating the fuel injectors20external power switches6are used.FIG. 14Bis essentially the same asFIG. 14A. However, in this example a separate peripheral IC2′ is used for each cylinder. The angle sensors are connected only to the peripheral IC2′ of the first cylinder, which thus includes the master angle estimation circuit as described with reference toFIGS. 11 to 13. The Performance Cluster1′ and the remaining peripheral ICs2″ include the essentially the same slave angle estimation circuit. That is, the angle information used by the peripheral ICs2″ is synchronized with the angle information available in the first peripheral IC2′. Alternatively, different groups of two or more cylinders could be controlled by separate peripheral ICs. This example also illustrates that the angle synchronization as shown inFIGS. 12A-Cis not necessarily done between Peripheral IC and Performance Cluster but also between two different Peripheral ICs.FIG. 14Cillustrates a further option, according to which two peripheral ICs2′ and2′″ are used together with one Performance Cluster1′. The peripheral IC2′ (e.g. including the GDI driver) is basically what has already been discussed with reference toFIGS. 9 to 13. That is, peripheral IC2′ implements all auxiliary and supplementary functions with regard to time and angle related sensor signals and actuator events (e.g. fuel injection, ignition, intake air pressure sensor, etc), whereas peripheral IC2″ implements all auxiliary and supplementary functions with regard to only time related events (e.g. electronic throttle control (ETC), exhaust gas recirculation (EGR), selective catalytic reduction (SCR), etc.). In another example, a third peripheral IC (not shown) may implement common engine control functions, which neither require a highly precise timing nor a precise angle information. In any case, the peripheral ICs can communication with the Performance Cluster via the bidirectional high-speed real-time capable bus7.

FIG. 15illustrates further examples of how Performance Cluster1′ and Peripheral ICs can be interconnected and also illustrates the time and angle synchronization between the individual ICs. In the example ofFIGS. 15A and 15B, the peripheral engine control functions are shared between the Base Peripheral IC2aand the GDI Peripheral IC2b, which includes only the driver stage for actuating the fuel injectors. The Base Peripheral IC2ais connected to the angle sensors11,12and includes the master angle synchronization unit, to which the corresponding slave angle synchronization unit in the Performance Cluster1′ synchronizes. The time base (oscillator XTAL) is connected to the Performance cluster1′, where it determines the operation of the (master) clock103(PLL, see alsoFIG. 11). The (slave) clock203(PLL, see alsoFIG. 11) is synchronized to the time base connected to the Performance Cluster1′ via the serial bus7. The angle information is also regularly transmitted via the serial bus7as explained before with reference10FIG. 12A-C. In the example ofFIG. 15A, the GDI Peripheral IC2bis only time-triggered by the Base Peripheral IC2avia another serial bus7′ (e.g. a HSSL, High Speed Serial Link) connecting the Periphal ICs2aand2b. In the example ofFIG. 15Bthe GDI Peripheral IC2bis time-triggered by the Performance Cluster1′ via a second serial bus7connecting the Performance Cluster1′ and the GDI Peripheral IC2b. TheFIG. 15Cis essentially the same asFIG. 14Bwherein the angle synchronization between the Base Peripheral IC2′ (including GDI periphery for Cylinder 1) and the GDI Peripheral ICs2″ (including GDI periphery for Cylinders 2, 3, and 4) is explicitly indicated.

In the examples ofFIGS. 14B and 14CandFIG. 15two or more peripheral ICs are connected to one single Performance Cluster1′ via the bus7, wherein all devices (Performance Cluster and peripheral ICs) are arranged on one PCB within one ECU. This concept can be generalized to a “domain structure” as shown inFIG. 16, in which several Peripheral ICs are connected to a Performance Cluster, which is not necessarily located on the same PCB but can also be arranged in a separate electronic control unit. Accordingly, one control unit takes over the function of a master control unit A, which includes a Performance Cluster and at least one peripheral IC as illustrated in the previous examples. This master control unit A may be the control unit for a first domain, for example, the powertrain master control unit, which takes care of the combustion engine control (ECU engine control unit). All other connected control units are “smart” slave control units, each of which fulfils a specific purpose. In the present example, the smart slave control unit B takes care of a second domain such as the transmission gear control, and the smart slave control unit C takes care of a third domain such as the electric motor control (e.g. in case of a hybrid vehicle). The smart slave control units do not include separate Performance Cluster and communicate (off-board) with the Performance Cluster of the master control unit A via the bidirectional high-speed real-time capable bus, which, in the present example, connects different PCBs in differently packaged control units arranged in different locations within an automobile. Basically, the peripheral ICs in the smart slave control units B and C “share” the Performance Cluster with the master control unit. Each smart slave control unit, may include one or more peripheral ICs, power switches to actuate external actuators, as well as one or more separate ICs which implement, for example power supply of the respective control unit and safety functions. It is noted, however, that the application software for the control functions performed by the individual smart slave control unit is concentrated in the Performance Cluster in the master control unit.

According to the traditional ECU design approach, the mentioned “sharing” of the MCU is not feasible, as the current MCUs used in engine control units are highly application specific MCUs. In contrast, the Performance Cluster according to the novel design approach is basically designed to provide computing power whereas (almost) all application specific hardware is concentrated in the peripheral ICs and separate power stages as detailedly discussed above. Therefore, the Performance Cluster can easily be scaled for applications, in which various different Peripheral ICs (in different smart slave control units) are connected to the Performance Cluster to provide different control tasks in different domains of an automobile.

FIG. 16shows one example, in which the domain “powertrain” of an automobile has been subdivided into the divisions “combustion engine”, “transmission” and “electric motor”. However, the illustrated concept (i.e. the domain structure and each domain including a master control unit and several smart slaves) may be easily transferred to other parts of an automobile, for example, body control, advanced driver assistance systems (ADAS), etc. as illustrated inFIGS. 17A-D. Accordingly, the control tasks, which are to be accomplished in an automobile, are grouped into two or more domains. In the example ofFIG. 17, the four domains “Driving”, “Safety”, “Body/Comfort” and “Infotainment” are used to group the control functions used in an automobile. Each domain includes a master control unit that has one Performance Cluster, which provides calculation power for all divisions of the respective domains. The divisions can be regarded as separate electronic control units, each including at least one Peripheral IC connected to the Performance cluster of the respective domain via a high-speed reals-time capable bus (see e.g.FIG. 16). The master control units of the individual domains may be connected via a communication network such as Gigabit Ethernet.

FIG. 17Aillustrates the divisions of the domain “Driving”. Accordingly, the domain may be grouped into the divisions “Engine Control”, “Traction Control”, “High Voltage Battery” (in case of Hybrid Vehicles), “Charger”, Transmission”, “Vehicle Stability Control and Braking”, “Steering”, “Suspension”, “Parking Brake”, “Thermal Management”. As already mentioned with regard toFIG. 16, one control unit may assume the role of a master control unit, which includes the performance cluster. In the present example, this may be the control unit implementing the Engine Control (ECU).

FIG. 17Billustrates the divisions of the domain “Safety”. Accordingly, the domain may be grouped into the divisions “Airbag”, “PCS” (Pre-Crash-Safety System), “Parking Assistant”, “Cruise Control”, “LDWS” (Lane Departure Warning System), “ADAS” (Advanced Driver Assistance System), “LIDAR”, “RADAR”, “Camera” (e.g. Rear-View Camera), etc. Again, one control unit may assume the role of a master control unit, which includes the performance cluster. In the present example, this may be the control unit implementing the Airbag Control.

FIG. 17Cillustrates the divisions of the domain “Body/Comfort”. Accordingly, the domain may be grouped into the divisions “Window Control”, “Rear View Mirrors” (e.g. anti-glare functions), “Head and Tail Lights”, “Seat Control” (positioning and seat warmers), “Heating”, “Air Condition”, “Indoor Lights”, etc. In the present example, the control unit for the Air Condition may take over the role of the master control unit, whereas the other control units are implemented as “smart” slave units. However, it would be also possible to implement a master control unit without a specific peripheral IC. In that case, the master control unit does not directly control specific actuators but only indirectly by controlling the smart slave control units connected thereto.

FIG. 17Dillustrates the divisions of the domain “Infotainment”. Accordingly, the domain may be grouped into the divisions “Navigation”, “Dashboard”, “Telephone”, “Radio”, “Infotainment”, “Interfaces” (e.g. Wireless LAN), etc. In the present example, the control unit for the dashboard control may take over the role of the master control unit, whereas the other control units are implemented as “smart” slave units.

Some aspects of the embodiments described herein are outlined below. It is noted that the following is not an exhaustive enumeration of features but only an exemplary summary. One embodiment relates to an electronic control unit for controlling an automotive component is described herein. Accordingly, the electronic control unit comprises a Performance Cluster chip with first circuitry integrated therein (see, e.g.FIG. 10, Performance Cluster1), a Peripheral Integrated Circuit (IC) chip with second circuitry integrated therein (see, e.g.FIG. 10, Peripheral IC2′), a digital real-time communication link connecting the first circuitry and the second circuitry (see, e.g.FIG. 10, high-speed serial bus7), and a printed circuit board (PCB) carrying the first and the Peripheral IC chip. The first circuitry includes a Central Processing Unit (CPU) that executes application specific software (see, e.g.FIG. 11, CPU110), which includes at least one control algorithm for controlling the automotive component (e.g. a fuel injector, seeFIG. 1, injector20). The first circuitry includes a first clock generator circuit (see, e.g.FIG. 11, oscillator13, and PLL103) generating a master clock signal for the first circuitry, and the second circuitry includes a second clock generator circuit (see, e.g.FIG. 11, PLL203), which synchronizes to the master clock signal via the communication link and generates a slave clock signal for the second circuitry. Furthermore, the second circuitry includes at least one of: an interface circuit to couple at least one sensor (e.g. crank-shaft or cam-shaft sensors11,12, see alsoFIG. 1) and a driver stage generating a control signal for at least one actuator (e.g. a fuel injector, seeFIG. 1, injector20).

In one embodiment the second circuitry (in the Peripheral IC2′,2a, etc.) includes a control logic (see, e.g.FIG. 13A, sensor interface210and bus interface205), which is configured to transmit sensor information, which is used for controlling the automotive component, to the first circuitry via the communication link (e.g. bus7). The second circuitry may include a control logic (see, e.g.FIG. 13A, bus interface205, event prediction unit208), which is configured to receive trigger commands from the first circuitry via the communication link, the trigger commands triggering the at least one driver stage to generate a control signal. The first circuitry may be integrated in the Performance Cluster chip using a CMOS fabrication process, and the second circuitry may be integrated in the Peripheral IC(s) chip using a HV-CMOS or BCD fabrication process.

Another embodiment relates to an automotive control system. Accordingly, the automotive control system comprises at least a first master control unit (see, e.g.,FIG. 16, master control unit A), at least one first slave control unit (see, e.g.,FIG. 16, slave control unit B), and a digital real-time communication link (see, e.g.,FIG. 16, off-board bus7′) connecting the first master control unit with the first slave control unit. The first master control unit includes a Performance Cluster chip (see, e.g.FIG. 13B), which includes a Central Processing Unit (e.g. CPU107) that executes application specific software, which includes at least one control algorithm for controlling at least one automotive component. The first slave control unit includes a Peripheral Integrated Circuit (IC) chip (see, e.g.FIG. 13A), which is associated with one of the at least one automotive component and which includes at least one of: an interface circuit (e.g. interface210or SENT interfaces220,223, seeFIG. 13A) to couple at least one sensor and a driver stage (e.g. driver209, see FIG.13A) generating a control signal for at least one actuator. The Performance Cluster chip may include a first clock generator circuit (e.g. PLL103and oscillator13, seeFIG. 13B) generating a master clock signal, and the Peripheral IC includes a second clock generator circuit (e.g. DPLL203, seeFIG. 13A), which synchronizes to the master clock signal via the communication link to generate a slave clock signal for the first slave control unit.

The first master control unit may configured to control automotive components of a first domain (e.g. Driving Domain, seeFIG. 17A, or Powertrain, seeFIG. 16), wherein the at least one automotive component is associated with the first domain. The automotive control system may further include a second master control unit, which is configured to control automotive components of a second domain (e.g. Safety Domain, seeFIG. 17A). A communication network such as CAN or gigabit Ethernet (seeFIG. 17) may connect at least the first master control unit and the second master control unit. The automotive control system may further include at least one second slave control unit (e.g. Airbag Control Unit, seeFIG. 17B), a digital real-time communication link connecting the second master control unit (responsible for, e.g. the Safety Domain) with the second slave control unit.

Like the first master unit, the second master control unit may include a Performance Cluster chip including a Central Processing Unit (CPU) that executes application specific software, which includes at least one control algorithm for controlling at least one of the automotive components (e.g. the Airbag or the ADAS) of second domain (e.g. Safety Domain). Analogously to the first master control unit, the Performance Cluster of the second master control unit may include a first clock generator circuit generating a master clock signal, and the Peripheral IC of the second slave control unit may include a second clock generator circuit, which synchronizes to the master clock signal via the communication link to generate a slave clock signal. The second slave control unit may include at least a Peripheral IC chip, which is associated with one of the automotive components of the second domain. The Peripheral IC chip of the second slave control unit may include at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator.

Moreover, another embodiment relates to a control system for controlling automotive components associated with a first domain (e.g. Powertrain) of automotive components. Accordingly, the system comprises a Performance Cluster chip, at least a first Peripheral IC chip, and a digital real-time communication link connecting the Performance Cluster chip and the first Peripheral IC chip (see, e.g.FIG. 16). The Performance Cluster chip is configured to execute application specific software (e.g. using CPU107, seeFIG. 13B), which includes at least one control algorithm for controlling at least one automotive component of the first domain. The Performance Cluster chip includes a first clock generator circuit generating a master clock signal, and Peripheral IC chip includes a second clock generator circuit, which synchronizes to the master clock signal via the communication link to generate a slave clock signal for the Peripheral IC chip. The Peripheral IC chip includes at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator.

The at least one sensor (e.g. angular position sensor11, seeFIG. 11) is configured to measure at least one operation parameter (e.g. current passing through the fuel injector) of at least one of the automotive components (e.g. fuel injector20, see alsoFIG. 1) of the first domain, which are controlled the at least one control algorithm. The mentioned at least one actuator may be included in the at least one of the automotive components of the first domain, which are controlled the at least one control algorithm.

In one embodiment, the Peripheral IC chip may include a control logic (see, e.g.FIG. 13A, sensor interface210, SENT interfaces220,223), which is configured to transmit sensor information, which is used for controlling the at least one automotive component of the first domain, to the Performance Cluster via the communication link. Furthermore, the Peripheral IC chip may include a control logic (e.g. Event Prediction unit208, see e.g.FIG. 13A), which is configured to receive trigger commands from the Performance Cluster via the communication link. The trigger commands may trigger the at least one driver stage (e.g. driver209, seeFIG. 13A) to generate a control signal for the respective actuator.

The system may include a second Peripheral IC chip (see e.g.FIG. 14, one Peripheral IC per cylinder), and a further digital real-time communication link connecting the Performance Cluster chip and the second Peripheral IC chip. Like the first Peripheral IC, the second Peripheral IC chip may includes at least one of: an interface circuit to couple at least one further sensor and a driver stage generating a control signal for at least one further actuator.

Although various exemplary embodiments have been disclosed, it will be apparent to those skilled in the art that changes and modifications can be made according to a specific implementation of the various embodiments and without departing from the spirit and scope of this disclosure. It will be obvious to those reasonably skilled in the art that other components performing the same functions may be suitably substituted. Particularly, signal processing functions may be performed either in the time domain or in the frequency domain while achieving substantially equal results. It should be mentioned that features explained with reference to a specific figure may be combined with features of other figures, even in those where not explicitly been mentioned. Further, the methods of this may be achieved in either all software implementations, using the appropriate processor instructions, or in hybrid implementations that utilize a combination of hardware logic and software logic to achieve the same results. Such modifications to the concept are intended to be covered by the appended claims.

The following examples demonstrate one or more aspects of this disclosure and may be combined in any way.

An electronic control unit (ECU) for controlling an automotive component, the ECU comprising:a Performance Cluster chip with first circuitry integrated therein;a Peripheral Integrated Circuit (IC) chip with second circuitry integrated therein;a digital real-time communication link connecting the first circuitry and the second circuitry; anda printed circuit board (PCB) carrying the first and the Peripheral IC chip,wherein the first circuitry includes a Central Processing Unit (CPU) that executes application specific software, which includes at least one control algorithm for controlling the automotive component,wherein the first circuitry includes a first clock generator circuit generating a master clock signal for the first circuitry, and the second circuitry includes a second clock generator circuit, which synchronizes to the master clock signal via the communication link and generates a slave clock signal for the second circuitry, andwherein the second circuitry includes at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator.

The ECU of example 1,wherein the second circuitry includes a control logic, which is configured to transmit sensor information, which is used for controlling the automotive component, to the first circuitry via the communication link.

The ECU of any combination of examples 1-2,wherein the second circuitry includes a control logic, which is configured to receive trigger commands from the first circuitry via the communication link, the trigger commands triggering the at least one driver stage to generate a control signal.

The ECU of any combination of examples 1-3,wherein the first circuitry is integrated in the Performance Cluster chip using a CMOS fabrication process, andwherein the second circuitry is integrated in the Peripheral IC chip using a HV-CMOS or BCD fabrication process.

An automotive control system comprising:at least a first master control unit;at least one first slave control unit; anda digital real-time communication link connecting the first master control unit with the first slave control unit,wherein the first master control unit includes a Performance Cluster chip, the Performance Cluster chip including a Central Processing Unit (CPU) that executes application specific software, which includes at least one control algorithm for controlling at least one automotive component,wherein the first slave control unit includes a Peripheral Integrated Circuit (IC) chip, which is associated with one of the at least one automotive component and which includes at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator, andwherein the Performance Cluster chip includes a first clock generator circuit generating a master clock signal, and the Peripheral IC includes a second clock generator circuit, which synchronizes to the master clock signal via the communication link and to generate a slave clock signal for the first slave control unit.

The automotive control system of example 5,wherein the first master control unit is configured to control automotive components of a first domain, the at least one automotive component being associated with the first domain, andwherein the automotive control system further comprises a second master control unit, which is configured to control automotive components of a second domain.

The automotive control system of any combination of examples 5-6 further comprising:a communication network, which connects at least the first master control unit and the second master control unit.

The automotive control system of any combination of examples 5-7, wherein the communication network is a Controller Area Network (CAN) or an Ethernet network.

The automotive control system of any combination of examples 5-8 further comprising:at least one second slave control unit; anda digital real-time communication link connecting the second master control unit with the second slave control unit.

The automotive control system of any combination of examples 5-9,wherein the second master control unit includes a Performance Cluster chip including a Central Processing Unit (CPU) that executes application specific software, which includes at least one control algorithm for controlling at least one of the automotive components of second domain.

The automotive control system of any combination of examples 5-10,wherein the Performance Cluster of the second master control unit includes a first clock generator circuit generating a master clock signal, andwherein the Peripheral IC of the second slave control unit includes a second clock generator circuit, which synchronizes to the master clock signal via the communication link to generate a slave clock signal.

The automotive control system of any combination of examples 5-11,wherein the second slave control unit includes a Peripheral Integrated Circuit (IC) chip, which is associated with one of the automotive components of the second domain.

The automotive control system of any combination of examples 5-12, wherein the Peripheral Integrated Circuit (IC) chip of the second slave control unit includes at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator.

The automotive control system of any combination of examples 5-13, wherein the first domain relates to the powertrain of an automobile.

A control system for controlling automotive components associated with a first domain of automotive components, the system comprising:a Performance Cluster chip, at least a first Peripheral Integrated Circuit (IC) chip, and a digital real-time communication link connecting the Performance Cluster chip and the first Peripheral IC chip,wherein the Performance Cluster chip is configured to execute application specific software, which includes at least one control algorithm for controlling at least one automotive component of the first domain,wherein Performance Cluster chip includes a first clock generator circuit generating a master clock signal, and Peripheral IC chip includes a second clock generator circuit, which synchronizes to the master clock signal via the communication link to generate a slave clock signal for the Peripheral IC chip, andwherein the Peripheral IC chip includes at least one of: an interface circuit to couple at least one sensor and a driver stage generating a control signal for at least one actuator.

The control system of example 15,wherein the at least one sensor is configured to measure at least one operation parameter of at least one of the automotive components of the first domain, which are controlled the at least one control algorithm.

The control system of any combination of examples 15-16,wherein the at least one actuator is included in the at least one of the automotive components of the first domain, which are controlled the at least one control algorithm.

The control system of any combination of examples 15-17,wherein the Peripheral IC chip includes a control logic, which is configured to transmit sensor information, which is used for controlling the at least one automotive component of the first domain, to the Performance Cluster via the communication link.

The control system of any combination of examples 15-18,wherein the Peripheral IC chip includes a control logic, which is configured to receive trigger commands from the Performance Cluster via the communication link, the trigger commands triggering the at least one driver stage to generate a control signal for respective actuator.

The control system of any combination of examples 15-19, further comprising:a second Peripheral IC chip, and a further digital real-time communication link connecting the Performance Cluster chip and the second Peripheral IC chip.

The control system of any combination of examples 15-20,wherein the second Peripheral IC chip includes at least one of: an interface circuit to couple at least one further sensor and a driver stage generating a control signal for at least one further actuator.

These and other examples are within the scope of the following claims.