US20010016789A1

US20010016789A1 - Electronic control system

Info

Publication number: US20010016789A1
Application number: US09/443,658
Authority: US
Inventors: Dieter E. Staiger
Original assignee: Individual
Current assignee: International Business Machines Corp
Priority date: 1999-01-28
Filing date: 1999-11-19
Publication date: 2001-08-23
Anticipated expiration: 2019-11-19
Also published as: DE10000997B4; JP2000222370A; DE10000997A1; US6292718B2

Abstract

An electronic control system for controlling the function of a processing system is provided, especially for the use in an automotive vehicle, wherein said control system comprises a plurality of logical control elements, each of which is especially adapted to perform special tasks, whereby each of said control elements is able to communicate with every other control element.

Description

FIELD OF INVENTION

The present invention relates to an electronic control system for controlling the function of a processing system. In particular the invention relates to such a control system that can be used in an automotive vehicle.

BACKGROUND OF THE INVENTION

The appearence of electronically controlled vehicles controlled by so-called “electronic control units” (ECU) comprising a microcomputer has increased drastically in recent years. In addition to control of the rotational speed of the internal combustion engine, control of gear changeover in a transmission and control of a clutch, these vehicles also have various accessories controlled by the ECU. Based on signals from various sensors provided on a variety of actuators, which drive devices to be controlled, the ECU calculates control variables for the various actuators that are controlled and then outputs the corresponding signals to these actuators to control the operation of each device.

Control systems of this type are used, for example, in motor vehicles for performing control functions which are typically found in vehicles. In conventional systems, the control units are each specifically designed for one or several application functions. The implementation of a new vehicle function requires the design of a new respective control unit. Together with a new sensor and actuator configuration, this new control unit must then be installed in the vehicle.

Although the control units in modern configurations are networked, for example, via a CAN bus, no explicit interface exists for access to individual function components. As a result, the entire respective application function appears to the control unit. For implementing new so-called recombined functions, which are built from existing functions, the explicit interface must therefore be manually connected to existing functions, at a resulting high cost. This is accomplished, for example, by defining or changing corresponding CAN messages. Further disadvantageously, in order to add a single new function, this sometimes requires the changing of all of the other control units.

Together with the trend toward increasingly electronically implemented functions in motor vehicles and their increasing mutual coupling, a significant rise in complexity occurs, along with a corresponding difficulty in the development and mastery of the entire electronic system of the vehicle. Additionally, this leads to a rising demand for computing power and memory capacity. Moreover, as a result of the increasing complexity while there are simultaneously more and more series and shorter development times for these series, it is required that components should increasingly be capable of being used again in a series-spanning manner.

DESCRIPTION OF RELATED ART

Electronic Control Units (ECU) using embedded controllers and processing systems typically display a distributed HW layout. This means, the system topology of the majority of the embedded ECUs,—and resulting functional HW layout and required components—is defined ‘application specific’. That means that standard processing system implementations as used in the majority of embedded systems, display a typical system architecture with a topology featuring a centralized processing unit (CPU) connected to the various subsystems defined by the target application of the overall system. The individual subsystems are build to support ‘specialized’ applications slices, all together performing the overall system target application(s).

Given this facts, implementations according to the ground rules of the typical standard System-Architecture will reflect in widely differing HW-realizations using individual HW assemblies for the various subsystem.

FIG. 1 shows a block diagram of such typical system layout, as used and implemented for a wide range of embedded systems to the state of the art. It can be seen, that ECU functionality is spread over the whole system, thereby creating redundancies and a lot of individual communication paths. Thus, the functions are not fault tolerant, because the connected parts present cannot be used to full advantage due to the actual topography. In addition , these systems are not cost efficient, because they need a hardware overhead to realize the respective functions. The multiple implementation of identical functionality on the diverse sub-systems—to mention ‘power management’ for example—is leading to increased physical size of the unit and as further negative consequences, is increasing the overall system power consumption and has a detrimental effect to the system reliability (a higher count of involved electronic parts is reducing the system MTBF).

Typical cooperating elements connected to the CPU, are units like: a Real Time Clock (RTC), power-up-reset and boot control circuits, system environmental sensors (for example temperature sensors, humidity sensor, etc.), and CPU independent system-watchdog functions and -timers.

Major functional application/solution areas are usually represented by entire sub-Systems:

Power-Subsystem (covering on ECU power devices as well as external, general power systems)

Storage sub-System (silicon storage devices and potential external mass storage devices like hard drives and optical devices)

Real-time sub-System(s) covering direct connected real-time devices (DIO) and covering real-time bus interfaces tying into external real-time devices

Telematic sub-System(s) like radio transmitters and receivers, radar sensors, Modem and Phone and other devices allowing wireless communications and access to Wide Area Networks (WAN).

Human Interface System (or ‘Man Machine Interface’, MMI)—Mechanical I/O devices like switches, rotary knobs, joy-sticks; Graphical interfaces like simple indicators, alpha numeric displays, LCD displays etc.; Audio devices like undemanding signaling devices like beepers, horns or record players,—leading to complex voice control systems featuring voice recognition and voice output.

In addition to the domain-function of the respective sub-System, each of the indicated sub-Systems is typically covering functionality of power management, initialization routines, storage management, specific CPU and sub-System intercommunication and fault management—functionality covered redundantly—an fact given by the standard system architecture.

As a tribute to the distributed HW layout and the different individual internal sub-system solutions, there is no beneficial HW/SW communality among the diverse ECU apparatus—even though following ‘similar’ standard architecture implementation.

A further consequence, the basic system control functions, the power management, the system support functions and system interface functions as well as the system internal specific communication links are repeatedly represented by identical hardware devices located on the sub-Systems, as well as integrated within the main CPU or supporting chip-set.

Characteristic to the standard HW-architecture and systems in consideration, is the entirely different nature of ECU- and corresponding sub-System intercommunication.

FIG. 1 is representative for a wide range of embedded systems, as for example, beginning with simple controllers likely used in consumer products like dish-washers, micro-wave ovens, washing machines,—reaching out to more complex systems as for example used the wide range of products covered by the world of ‘pervasive computing’, thus as set-top boxes and multimedia devices. An entirely new playground of pervasive computing is invoked by the massive entry of multiple processing system into today's automobiles. Not only concentrating on vehicle domain functions, the processing platforms are used in extension to support new applications for client and remote server services. Already introduced and in the near future, modern vehicles will access external networks, allowing to provide services like remote diagnostics and maintenance, intelligent navigation using traffic information, facsimile mail, e-mail and last not least Internet access and services—were this list is not complete and will get extended dramatically in the upcoming years.

Remarkable to all systems pointed out is the fact, that the majority of applications served by the system—even though mainly executed by the individual sub-systems within the ECU, are loading the main CPU to some extend—or, in some cases significantly. To mention for example—all real-time functions as well as the non-real-time functions like the MMI caused routines and sub-system power management functions—are ‘loading’ the main CPU. In addition, the various ECU internal and system external communication links (like real-time bus induced interrupts, LAN and WAN connectivity), directly ‘reporting’ to the CPU are encounter demand for further CPU performance.

In consequence, the designer has to ensure sufficient processing performance (CPU MIPS)—oversized in comparison to the required MIPS rate defined by the system applications—to ensure proper system operation covering the most potential peak loads to expected.

FIG. 2 shows a system bus communication scheme typically used in a majority of processing systems (as for example Intel based Personal Computers). The bus structure is hierarchical oriented. The CPU local bus normally represents the bus, featuring the highest bandwidth performance. The CPU and closely related units and sub-systems are connected to this bus. A bus bridge is establishing the gateway to the next lower level bus system. In personal computing systems, this would typically be the PCI bus.

The benefits obtained by this architecture, is given by the simultaneous, undisturbed communication of units within their bus level.

However, all communications requiring units from the higher level bus (or vise versa) to access units located on other bus levels, will have to ‘path’ via the gateway provided by the respective bridge device.

The drawback of this bottleneck encountered by the standard bus structure is apparently, and needs not to be explained. A further disadvantage is given by the ‘single usage in time’ for this bus structure. For example, two bus participants communicating on one level, will obstruct not only the communication for other units located on this bus, further more, it is for this time unattainable for units located on an other bus levels to contact any unit on the former.

Dedicated SW and HW modules are used to allow extensive bus protocols, required to managing and to control the various communication types like M/S (Master/Slave) methods and DMA (Direct Memory Access) techniques.

In the Japanese Application No. 60-217471 there is disclosed a control system, wherein the electronically controlled vehicle described not only includes an ECU (main controlling unit) for controlling various actuators, it is also equipped with emergency actuators for back-up purposes in the event that any actuator or the main control unit itself develops an abnormality such as breakage of a wire or short circuit, and an emergency ECU for controlling the emergency actuators.

U.S. Pat. No. 4,910,494 discloses an automotive vehicle control system including fault detection means provided in the main ECU for diagnosing faults in monitoring the emergency ECU.

In EP-A-0 862 296, there is described a data communication system comprising a plurality of ECUs used therein, each including a central processing unit for controlling an electronic device, and each of the ECUs communicating with other ECUs under a predetermined data transmission protocol.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide an electronic control system that allows to build up a highly efficient embedded processing system having high reliability and fault tolerance.

It is another object of the present invention to provide such a system that is advantageous in Processing Platforms requiring to perform real-time applications in coincidence with non-real-time applications.

It is still another object of the present invention to provide a control system architecture that is beneficial in a variety of pervasive computing applications.

These and other objects are achieved by providing an electronic control system for controlling the function of a processing system, comprising a plurality of logical control elements, each of which is especially adapted for carrying out special tasks, whereby each of said control elements is able to communicate with every other control element.

The present invention, called Tetrahedron Control element Topology (TCET), is describing a principle and system topology for processing/computing systems, advantageous enabling to build Electronic Control Units (ECU) distinguished with prime system efficiency and system availability. The proposed system is comprising the attributes of providing basic fault tolerant behavior, supporting the efficient build of extensive fault tolerant systems, fault recovery, or fault fall-back mechanisms.

The TCET principle is maintaining minimum system overhead, concerning hardware- as well as software-resources, to provide basic fault tolerance. The principle is utilizing the system HW resources to a maximized efficiency, thus being fundamental to allow system realizations at minimum cost.

The proposed architecture is reducing the overall system components and subsystems to a core-set of four individual logical main control elements—organized in unique processing topology. Each one of the Control elements is individually defined to cover sharply outlined functional responsibilities—precondition for dedicated solutions, optimally solving the specified set of tasks. The Control elements are cooperating in a unique intercommunication scheme, avoiding functional ‘overlapping’ HW-areas or SW modules within the overall system, as typically given by implementations utilizing standard system/subsystem architecture solutions.

An important key of the proposed idea is, to organize the identified control elements in a cooperating Tetrahedron geometry providing:

a) simultaneous multi-path communication the respective elements

b) real-time capability to all ECU hardware near components, subsystems and networks

c) secure access to system external units (located on LAN, WAN and wireless)

The TCET principle for the combined electronic circuit arrangement and software partitioning is allowing to build highly efficient embedded processing systems, featuring high system reliability and system processing availability. Efficiency by means of—in direct comparison to ‘standard’ processing system solutions—significantly reduced amount of electronics circuitry and system complexity, required to achieve the respective system target application(s). Further more, the principle delivers an optimal base structure supporting to buildup fault tolerant systems at minimum cost overhead.

TCET is profitably put in action for processing platforms requiring to perform real-time applications in coincidence with non-real-time applications.

Furthermore, this architecture is beneficial in a variety of pervasive computing applications.

In addition, this solution can be used with large scale computing systems, as well as with standard office computing systems, e.g., “Personal Computers”, very low end/low cost embedded systems and game computers. This list is exemplary only and not limiting.

DETAILED DESCRIPTION OF THE INVENTION

To reach the targeted attributes of the invention, it is essential to redefine the system topology and to find a new system organization and internal structure featuring reduced overlap and redundant functionality in the CPU and the corresponding sub-systems. As a leading guideline, each sub-systems is to be defined to cover a specific, sharply outlined task spectrum. In this manner, it is possible to build optimized functional sub elements perfectly matching the requirements of the dedicated portion of tasks. To finally reach the objectives, it is indispensable to organize the sub elements in a topology allowing a highly effective intercommunication of the cooperating elements. [0046]
Three major maxims are used to lead to the proposed new ECU-principle and architecture. [0047]
(1) Reorganize the HW-Subsystems and Functional HW-elements and identify new logical elements concentrating on specific and interrelated tasks. At this stage it is important to understand, the logical elements are not necessarily to be represented by HW performing the tasks and applications in focus. Target is to avoid functional overlap of the newly defined logical elements—further called Control-Elements (C[0048] 1 . . . Cn)—and to avoid redundant functionality spread out on the Control elements Cn.
(2) Define a new hardware and software system topology build upon the identified logical Control elements. Each Control element to be unique and to allow/support independent operating software by means of individual custom tailored Operating Systems, SW-Layers and drivers and specific Control element applications as appropriate. [0049]
(3) Define a Control element intercommunication scheme, providing the attributes efficient, secure and reliable for the communication ECU system internally as well as to all respective external communication links. The objective is, to avoid the drawbacks as known by standard architecture implementations (as described above). The communication path from any control element to any other control element to be invisible to the overall ECU application programs. As a ground rule, it is important to avoid specific, to task customized communication links interconnecting the individual control elements. [0050]
In addition to the ECU internal communication scheme, a secure solution allowing to access the ECU related real-time-networks and -subsystems as well as to communicate to system external extensions accessed by standard networks (LAN, WAN and wireless) has to be provided. Typical to this external network link is ‘plug-and-play’ capability and the potential for external users and systems to enter unauthorized. [0051]
The three maxims described above will now be explained in greater detail. [0052]
Maxim 1: Identify logical Control elements C[0053] _n
FIG. 1 is used to analyze distributed functionality in a system implemented conform to standard system architecture and to define the new Control elements as demanded by [0054] maxim 1.
The first objective is to categorize functions and hereafter to assign directly related functions to on specific logical Control element. This concentrated collection of related and potentially directly communicating functions within one logical Control element will allow to define a highly effective solution. [0055]
A detailed examination of the ‘standard system’ uncovered a minimum set of four major functional areas. Each of one is covering a specific field of applications and services. The base idea is to define individual, custom tailored Control-Elements (C[0056] 1, C2, C3 and C4), providing exactly the functionality demanded by each area.
In the next step, the four areas identified, are defined as Control elements C[0057] 1 to C4. At this point it is important to state, the identified Control elements are defining the logical functions assigned to the individual Control elements—and are not necessarily to be represented by hardware.
Functional summary of the Control elements C[0058] 1 to C4
In the following, the functional tasks of each of the four control elements are given. [0059]
Control element C[0060] 1 ‘SysMon’ (System-Monitor)
Power management (shutdown unused power sources, control voltages) [0061]
System power on control (power sequence, power good) [0062]
System boot sequence generation and monitor (error monitor and fallback solution control) [0063]
System vitality monitor (sense temperature, humidity, poll functional vitality indicators of the other control elements) [0064]
System standby and sleep control [0065]
System fault handling [0066]
Control element C[0067] 2 ‘ComPro’ (Communication Processor)
Real-time applications [0068]
Real-time network access and control [0069]
Gateway to the non-real-time sub-systems and networks [0070]
System fault handling [0071]
Control element C[0072] 3 ‘MMI/A’ (Man-Machine-Interface and general Application)
Main ECU system applications [0073]
Human interface applications and I/O functions (mechanical I/O, visual I/O, voice/audio I/O) [0074]
Multi-Media applications (video and audio processing) [0075]
System fault handling [0076]
Control element C[0077] 4 ‘CAP’ (Common Access Point)
Concentrated access point for system internal communication [0078]
System expansion link to external communication [0079]
System fault handling [0080]
Maxim 2: Logical System Partitioning [0081]
As per definition by the TCET principle, each control element is defined to operate independent and to execute its own specific field of applications. To adjust to the different nature of applications and to meet the system objectives as outlined, it is obliged to realize the control elements by using individual solutions, represented by hardware (HW) and/or software (SW), uniquely defined to best meet the specific requirements. [0082]
As already explained before, the logical control elements must not necessarily be represented by separate processors and/or hardware units. Depending on the overall system functionality, it is possible to realize the proposed TCET architecture by implementing the logical control elements on a single processor system as well. In this case, functional control elements can be solved by integrated HW-extensions, or even be replaced by SW-equivalents. [0083]
Concentrating on the identified individual spectrum of functionality for each Control element, will lead to a custom tailored solution, perfectly serving the specific field of operation. Redundant elements, as known by prior art, are kept to a minimum. The benefit for the overall TCET system is featuring minimum resource overhead on hardware and software—an important fact to reach the overall system cost, performance and functional targets. [0084]
HW/SW implementation for typical embedded systems can be as follows: [0085]
Control element C[0086] 1 (SysMon)
Hardware solution: A typical representation would be a low end 8 bit controller, or in certain occasions, a dedicated sequencer design integrated in an ASIC. An implementation, perfectly suiting the requirements for the majority of systems, could be, for example, a low end μController chip of the ‘PIC’ controller family supplied by Microchip. [0087]
Operating System and Application Software: The preferred solution will not require an Operating System. The application are programmed in lowest level HW language. This will lead to very compact and effective code directly executed by the HW. The SysMon algorithms, programmed in μ-Code, are stored as ‘firmware’ in ROM or EERPOM, and are typically integrated on the SysMon component. [0088]
Plain software implementation: The SysMon functions will be represented by SW modules executed by either C[0089] 2 or C3. This solution would typically be chosen for very small embedded systems.
Control element C[0090] 2 (ComPro)
Hardware solution: The emphasis for the ComPro is on minimum interrupt latency and minimum interrupt handler execution time. This is important for the hardware (micro controller and involved storage system) as well as the software executed by the SW (interrupt handler stack). Depending on the amount and complexity of real-time applications to be provided, the ComPro can be realized in the low-end by a dedicated programmable state machine, in the high-end by a standard 32 bit micro controller. For the majority of system a 8 or 16 bit controller would be used. [0091]
Operating System and Application Software: [0092]
a) Real-time Operating System (RTOS) micro controller specific (for example OSEK, QNX and others) [0093]
b) Low-end solution: Directly programmed real-time sequencer (in hardware or firmware). [0094]
The operating system OSEK—an emerging standard in Europe—is pretended to be used by the majority of vehicle manufactures. A very powerful OSEK implementation—developed by IBM and called AR/OS (Automotive Real-time Operating System)— designed to exploit the PowerPC Architecture. AR/OS is configurable and comprises a full-featured real-time executive and a rich collection of optional libraries providing open network interfaces and extension supporting ANSI C and POSIX standards. The real-time executive provides the basic services defined in the draft POSIX real-time—meeting the needs of memory-constrained deeply embedded systems. The combination using a PowerPC and AR/OS, will enable the ComPro to support a wide spectrum of applications. [0095]
Plain software implementation: In TCET ECU implementations requiring [0096]
a) very high performance to be provided for the control element C[0097] 3 applications and
b) only low demand on real-time functions and interfaces, it is meaningful to realize the ComPro functions in SW-modules executed by the C[0098] 3 micro processor. In this type of realization, the C3 micro controller should provide an Memory Management Unit (MMU) allowing to separate the C2 code from the C3 code and applications. This is essential to allow the implementation of software models guaranteeing secure operation (separating the real-time world from the ‘unsecured’ plug-and-play systems potentially attached to the C3 element.
Control element C[0099] 3
Hardware solution: C[0100] 3 is the control element typically dealing with human interface components and multi-media units, is showing the highest demand on processing performance (high MIPS rate) withing the TCET ECU. Interrupt latency and minimum interrupt handler execution time is normally uncritical. For this reason, the C3 is realized by standard 32-bit micro processors for the majority of systems. However, for low-end systems requiring only simple MMI support, a 16-bit or 8-bit micro controller solution may be sufficient.
Operating System and Application Software: The control element C[0101] 3 is typically operated by standard Operating Systems (like for example QNX, WIN-CE and others) providing graphics support. In case of applications related to internet access and e-mail functions, a preferred solution can be a RTOS featuring a integrated JVM (Java Virtual Machine). In this solution, the C3 applications would be implemented in Java programs and applets.
Plain software implementation: typically not applicable— however, very low end systems with only few human interface functions and higher focus on real-time-connectivity and -applications, can be realized in by a more powerful C[0102] 2 implementation, allowing to exercise the C3 software applications as well. For the same reason as explained for the plain software implementations explained for C2, the chosen micro controller for this type of logical C3 realization should provide a MMU.
Control element C[0103] 4
Hardware solution: The control element C[0104] 4 is typically implemented in a hardware-only solution. In most cases a standard net-work controller can be used. In ASIC-solutions for the TCET ECU, a dedicated solution for C4 is leading to the best and most cost effective implementation. For low-cost implementations, a Field Programmable Gate Array (FPGA), complementing smaller standard bus-controllers to build up the C4 functionality, can be meaningful.
Operating System and Application Software: As the C[0105] 4 is typically a hardware-only solution, the C4 algorithms are provided by specific micro-programs executed by the hardware. The code implemented in firmware and is stored in ROM or EEPROM—normally integrated on the C4 device.
The C[0106] 4 element is not providing any TCET ECU application function, and is for this reason ‘invisible’ to the system application software. The driver software potentially required for the net-work access, will be added to the respective operating systems used for C2 and/or C3.
Plain software implementation: This type of implementation would be ‘considered’ untypical TCET realization—however, can be done if meaningful. The C[0107] 4 functionality in these cases would be provided by SW-modules and hardware extension on either C2 or C3.
Maxim 3: Cooperative operation of TCET control elements C[0108] _n
In general in can be distinguished between two different types of communication of the TCET system and overall system environment. To begin with the TCET ECU internal communication, links allowing the Control elements C[0109] 1 to C4 to communicate among each other have to be provided. The second type of communication is considering all interaction links leading to the TCET ECU outer world.
In consequence to the TCET principle, as defined in [0110] maxim 1 and 2, the diverse TCET ECU external communication links are assigned to the respective, to this type of communication specialized, Control element. This is an important fact leading to the objected TCET attributes for system security and reliability—reasonable after understanding the specifics of the TCET ‘outer links’.
The TCET ‘outer links’ [0111]
The connections to the real-time related world (FIG. 3, communication path i) is provided by the ComPro (C[0112] 2). All applications, dealing with real-time functionality are executed by this control element.
The SysMon (C[0113] 1) is connected to the external power subsystem and general system supporting devices (FIG. 3, path k). Both links, i) and k) are dealing with closely ECU related and hardware support functions. An example to illustrate the nature of this type of communication: in an automobiles, this system are connecting to safety relevant- and critical system functional-elements like the braking system, the transmission control, light control and others.
Tying into the so called ‘unsecured’ world, the CAP (C[0114] 4) is providing the communication link to system extensions and establishing access to LAN, WAN and wireless connectivity (FIG. 3, path m and p). ‘Unsecured world’ by means of networks, allowing the system user (e.g. vehicle driver or passenger) to plug in new devices (‘plug-and-play’, devices like a PDA, CD-player, Modem and others) as well as providing entrance to far away systems, including access to Internet.
This separation, polarizing the real-time related applications on the ComPro and focusing the ‘un-secured’ plug-and-play world on the MMI/A (C[0115] 3) and the CAP (C4)—is providing the perfect pre-condition supporting the implementation of secure gateways—thus, isolating the critical applications.
The TCET ‘inner links’ [0116]
The TCET internal links (FIG. 3, paths a, b, c, d, g and f) are interconnecting the control elements C[0117] 1 to C4. All of this connections are used to support multiple types of communication tasks. One type of tasks, considering all internal links, can be summarized as ‘system internal management and control’ function. Typical internal management functions are: power management, boot control, system test and vitality check, and last not least, providing communication capability to support for fault tolerant strategies.
The communication link b) is mainly used to allow data exchange between the ComPro and the MMI/A control elements. Depending on the extend of applications to be executed by two mentioned Control elements, this link has to provide a transmission bandwidth beginning at 1 Mbps for typical systems, and in case of e.g. graphical information has to be exchanged, the demand on bandwidth may easily go up to as high as 20 or more Mbps. [0118]
The links d), f) and g) are connecting the control elements C[0119] 1 to C3 to the CAP (C4)—thus allowing the access to the system ECU expansions. The bandwidth to be provided for this links is mainly defined by the external units to be connected, and is typically at least as high as the bandwidth required for path b).
As a guideline for the implementation of the TCET principle, it is advantageous to realize all TCET ‘inner links’ featuring identical performance and arbitration capability. This will provide multiple choice for the diverse communication types to be performed, thus leading to the objectives for high system availability and effectiveness. Further more, the multi-path link capability, supported and utilized by ‘fault recovery’ algorithms, optionally provided by C[0120] 1 to C4, will represent a basic fault tolerant behavior and will enable effective implementations for further fault management.
The TCET ECU internal communication can further be classified to links staying ECU internally, by means of information exchange exclusively within the TCET elements, and by links being part of an wider communication path, leaving the ECU by external network. For further explanation, these links are labeled iL (immediate Link) for the internal links and aL (arbitrated Link) for the ECU external links. [0121]
Immediate Link (iL) [0122]
The control elements C[0123] 1, C2 and C3 are interconnected by the links a, b and c. According to the TCET principle, this links are defined as bi-directional point-to-point connections. Each one of these links implies a maximum of two communicating participants.
As guideline for the implementation of the TCET principle, it is required to provide independent points of access on each end of the enumerated communication paths—regardless of overall system implementation model (HW and SW partitioning). [0124]
In case of a physical representation for a control element (HW solution), this would mean individual, independent transceiver devices for each link—in SW implementations respectively independent driver elements. [0125]
The realization for this type of communication path(s) is very simple—for both ways, SW and/or HW. Interrupt driven solutions are typically preferred, however, depending on the overall system implementation, polling techniques can be meaningful as well. Since only two points are to be addressed, higher demand for transmission speeds (for the typical bandwidth in focus) is not influencing the HW cost by significance. [0126]
Arbitrated Link (aL) [0127]
The communication paths d, f and g are connecting to the CAP (C[0128] 4), and are via C4 enabled to tie into external networks. External networks can be represented by LAN and WAN—and for both network types, wireless connectivity is a valid implementation. Typically these external communication paths are represented as multi-drop networks, requiring arbitration, permitting to gain and to control bus access and communication rights.
For the ECUs in focus, such as in general embedded systems and pervasive computing devices, it is obvious to apply a decentralized bus access schemes. Standard bus access techniques like CSMA/CD (Carrier Sense Multiple Access/Collision Avoidance) or CSMA/CD (Carrier Sense Multiple Access-/Colli-sion Detect) and related procedures represent the typically used bus access methods. [0129]
Depending on the field of TCET ECU application, transport capability for IP-frame based communication, asynchronous, synchronous and isochronous data transfer has to be established. [0130]
The following applies in generall to all TCET internal links: [0131]
For compatibility purpose and ease of implementation, the transport capability of IP frame based message exchange is preferred and advantageous for the majority of systems, requiring access to standard LAN, WAN and Internet,—valid for all TCET ECU internal links. [0132]
The TCET ECU links (summary of attributes, requirements and typical representation) [0133]
TCET system C[0134] 1 . . . C4 internal communication
a), b), d) SysMon task related communication [0135]
requirement: low volume data, low speed [0136]
c) Application driven communication/Firewall data exchange (i.e. IP-frames) [0137]
requirement: medium to high volume data and speed [0138]
g), f) communication to external expansion devices [0139]
a) SysMon task related, (power management, vitality monitor, test) [0140]
requirement: low volume data, low speed [0141]
TCET system C[0142] 1 . . . C4 external communication
i) real-time ‘near’ HW communication (i.e. CAN, VAN networks) [0143]
requirement: 10 Kbps to 1 Mbps, deterministic behavior [0144]
k) SysMon/power-sub-system communication/power management (IIC bus, SPI, and others) [0145]
requirement: low volume data, low speed (typ. 100 Kbps) [0146]
l) MMI/Application sub-system communication (local devices) [0147]
requirement: application dependent, graphic data I/O e.g. 10 Mbps [0148]
m) system expansion bus (LAN; remote devices) [0149]
requirement: application dependant, typically 10 . . . 100 Mbps (and more) [0150]
TCET internal Communication Ground Rules [0151]
Using the following summarized ground rules as a guideline will lead to advantageous attributes for the implementations conform to the TCET principle. Nevertheless, depending on the requirements of a system to be developed, derivatives not following all points may have to be encountered. Understanding the tradeoffs and limitations, the TCET implementation will still provide its generic profitable attributes. [0152]
Individual access ports for each link to be provided for each control element [0153]
No direct electrical coupling (or optical, in case of optical link) between the internal communication ports of a control element [0154]
Individual SW driver modules for each link port for each control element [0155]
Provide identical bandwidth for all TCET inner links (specified by the highest data rate required) [0156]
Capability for simultaneous bi-directional communication for each inner link [0157]
Provide asynchrony, synchrony and isochrony data transport characteristic [0158]
Provide programmable message frame structure (e.g. support IP frame based message exchange) [0159]
Provide programmable priority tables for all TCET communication types (preferable accessible by all control elements)—including a exceptional message routing/handling for e.g. emergency communication. [0160]

Detailed Description of Control Elements C1 to C4

Control element C[0161] 1 ‘SysMon’ (System Monitor)
FIG. 4 shows the function of control element C[0162] 1 (SysMon).
The SysMon is assigned to the ECU internal functions and is an important component enabling the fault tolerant behavior of the overall system. Main duties are power-management, including sleep and wakeup control, watchdog-functions, and monitoring the vitality of the CSE system components. The communication link required to enable power management can be established by a slow speed standard SIO link to the Primary Power subsystem, such as for example SPI or I[0163] ²C.
Depending on the individually specified system requirements for fault recovery mechanisms, controlling the fault recovery elements may become the main task for the SysMon. The performance to be provided by this control element is defined to a wide extend by the implementation of this task. [0164]
The communication links connecting to the remaining control elements, as well as the algorithms for defining the fault behavior and fault recovery functions are, in accordance to the TCET architecture, advantageous implemented identical for all control elements. [0165]
As well as C[0166] 2 and C3, the SysMon is observing the 3-way internal/external communication links. It is enabled to automatically reorganize the ECU internal path of information transport upon faulty behavior.
Control element C[0167] 2 ‘ComPro’ (Communication Processor)
FIG. 5 shows the function of the control element C[0168] 2 (“ComPro”).
The key job assignment for the ComPro is dealing with all real-time applications of the TCET ECU. For this reason, the ComPro is the central communication element, connected to all TCET-ECU internal and ECU extending real-time networks. In addition to this, the TCET-ECU is connecting to ‘closely related’ hardware units. This type of devices are supported by special I/O ports like: digital I/O (DIO), analog I/O (AIO), infrared communication links (IrDA), Smart-Card and other interfaces. Some of this functionality, if not strong real-time concerned, can also be provided by the control element C[0169] 3—thus still being conform to the TCET architecture.
The concentrated access to all real-time networks going along with the communication possibility within this control element makes the ComPro ‘the element of choice’ to provide bridging, routing and gateway functionality. In this applications scenario, the ComPro can be build to support complex message filtering and message morphing— thus taking significant processing strain from the control element C[0170] 4.
Furthermore, provided by the TCET internal communication architecture, the ComPro has access to all additional communication paths like multi-media links and all types of LAN and WAN connectivity. [0171]
Typical representatives for the real-time links are field-busses like CAN, J1939, VAN and others. The hardware solution for the ComPro has to provide real-time capable electronics with focus on minimum interrupt latency and high speed interrupt handling support. The importance for general processing performance is of secondary nature. [0172]
Connecting to e.g. three individual CAN networks, and in addition tying into sub-control element feature-links and feature-I/Os, may cause interrupt rates of more than 15000 interrupts/second to be handled by the ComPro processing system. [0173]
The communication link sub-System and the fault behavior algorithms and functions are, in accordance to the TCET architecture, advantageous implemented identical for all control elements. [0174]
As well as C[0175] 2 and C3, the SysMon is observing the 3-way internal/external communication links. It is enabled to automatically reorganize the ECU internal path of information transport upon faulty behavior.
Control element C[0176] 3 ‘MMI/A’ (Man-Machine Interface/Application)
The function of control element C[0177] 3 is shown in FIG. 6.
The control element C[0178] 3 is covering the most demanding TCET ECU system applications. In addition, the human interface operations and going along I/O support, are significant functions to be performed by this element. The MMI interfaces are covering mechanical I/Os (like sensors and actors), visual I/O (like cameras and displays), and last not least voice/audio I/O (like microphones and speaker devices). The concentrated collection of this type of I/O devices distinguishes the MMI/A as the predominant element to perform the increasing range of Multi-Media applications and Telematics applications, including video and audio processing.
Future MMI systems, even more than Multi-Media- and Telematics Systems are demanding very high computing performance: Displaying three-dimensionally, and being visible ergonomically in the dynamic light situations as for example occurring in vehicles in motion, enforces very high 2D/3D graphical performance. Especially new I/O devices, like innovative ‘one-hand’ operating controls, automotive equitable ‘tolerant’ touch screen overlays, or ‘hands-free’ devices using voice recognition and speech synthesis, are defining the demand for high computing power for this control element. [0179]
Typically 300 MIPS have to be provided for standard MMI/MM systems are foreseen already today. The lowest limit for ‘highly cost constrained entry-systems’ is estimated to 100 MIPS. [0180]
Numerous processors on the market are capable to satisfy the computing power demand. However, system cost restrictions in the embedded world, and high reliability as for example required by ECUs used in automobiles, are reducing the number of choices significantly. [0181]
The communication link sub-System and the fault behavior algorithms and functions are, in accordance to the TCET architecture, advantageous implemented identical for all control elements. [0182]
As well as C[0183] 2 and C3, the SysMon is observing the 3-way internal/external communication links. It is enabled to automatically reorganize the ECU internal path of information transport upon faulty behavior.
Control element C[0184] 4 ‘CAP’ (Common Access Point)
FIG. 7 shows the function of control element C[0185] 4.
The control element C[0186] 4 is concentrating the communication links connecting the inner ECU world with the outside. Acting as the Common Access Point, the CAP is the only point, external systems are enabled to enter and to communicate with the TCET ECU. This single point of access, allowing external ‘unprotected’ devices to communicate with the TCET ECU, is an important feature of the proposed architecture, supporting to build fault tolerant systems and, in conjunction with the task-assignment as described for C2 and C3, cost effective secure gateways. The collaboration of all control elements is the key to the advantageous attributes of the TCET principle.
Three communication ports d), g) and f) are provided at the primary side of the CAP, establishing the communication links to the ECU internal control elements. The internal communication ports are preferably mutual electrically isolated by individual physical transceiver devices, connecting to the other TCET control elements. [0187]
The secondary communication port m) is connecting the TCET ECU via LAN and/or WAN to the ‘outer world’. The communication path m) is typically enabled for ‘plug and play’ operation, to allow the system-user or -operator to add on new, system function expanding devices. For fault tolerant reasons, this port can be represented by a plurality of physical transceiver devises. [0188]
The external networks (LAN, WAN) are usually multi-drop networks, requiring C[0189] 4 to provide arbitration capability, to obtain bus rights for C1/C2/C3-communication to the external net.
The CAP is isolating the external units from the ‘inner CSE’ elements. From a SW-perspective, the CAP function is comparable with a repeater, and is therefore invisible. [0190]

TCET Solution—Summary to Theory of Operation

In following the maxims, as explained above, individual, custom tailored logical control elements are determined, defined to exactly provide the functionality demanded by each application/task area. [0191]
Depending on the target system requirements, the control elements C[0192] 1, C2 and C3 are forming the core system functionality. These Elements are typically represented by dedicated, individual processors and/or specific HW-elements and/or software modules. Control element C4 is functioning as ‘Common Access Point (CAP). C4 is connected to all TCET ECU internal Control elements on the internal (primary) side, and is providing communication links to ECU external systems and expansion units on the secondary side. In this instantiation, Control element C4 is concentrating the entire external system communication—implying the potentially ‘unsecured plug-and-play’ world and Internet connectivity hazards—on this single point of access.
FIG. 8 displays a summary to the four main Control elements C[0193] 1 to C4 for the logical representation and the physical instantiation of the specific tasks to be provided.
The SysMon (C[0194] 1), the ComPro (C2) and the MMI/A (C3), providing the general ECU functionality, are organized in a communicating triangle. Each one is individually connected to the respective two neighbour control elements.
Establishing the ECU external connectivity, an individual communication link provided for each, C[0195] 1, C2 and C3, is connecting the TCET internal elements via the CAP (C4) to the outer world—thus building up an inter-linked control element system, forming the geometric of a Tetrahedron.
This structure is essential to the advantageous attributes of the TCET principle. The system architecture is concentrating related tasks and applications on specific, optimized control elements. This statement is an important key, allowing to build cost effective, highly efficient systems, avoiding functional overhead, leading to redundant code and circuitry. Further more, the TCET organization for the ECU internal and external communication is essential supporting to build high performance systems. The TCET topology is providing simultaneous multi-path link capability, thus overcoming communication bottlenecks and providing basic fault recovery potential. [0196]
In addition, this system topology is a fundamental prerequisite supporting implementation variants, featuring fault tolerant system behavior on demand. [0197]

System Fault Handling

The control element C[0198] 1 (SysMon) is in general monitoring the system vitality and controlling the system fault fall back behavior. The TCET system architecture presents an ideal precondition, allowing to implement comprehensive fault fall-back behavior logistics. Already furnished with a fault tolerant communication structure, the overall system fault behavior can be extended very effectively.
To a wide extend, this can be achieved, by adding, potentially small, ‘system fault handling’ test routines and fault recovery routines to each control element, allows to implement a very effective system fault recovery strategy. [0199]
Techniques like adding on redundant elements and subsystem, as most commonly used in standard system implementations, are certainly supported by the TCET principle as well. In this type of fault tolerant implementations, the TCET topology is still advantageous for cost effective realizations. [0200]
An example scenario, outlining a basic fault tolerant TCET implementation is as follows: [0201]
The communication path iL_[0202] 3, connecting the ComPro with the MMI/A is for any reason disrupted or obstructed for a period of time.
To overcome this system-fail situation, an algorithm can be defined, automatically utilizing alternative communication paths, provided by the TCET principle. This consequent re-routing will be initiated automatically in the background, thus invisible to the basic application executed in this moment of time by the ComPro and MMI/A. [0203]
The alternative communications paths for this example are: [0204]
(1) iL_[0205] 1-iL_2 or (2) iL_1-aL3-aL2
In this type of implementation, it is most effective to realize the logistic for this routines identical for all involved control elements. [0206]
The key advantages are a highly cost efficient system framework supporting and enabling [0207]
Cost advantage by reduced amount of overall hardware components [0208]
Reduced physical size [0209]
Minimized power consumption [0210]
Basic fault tolerant system structure as precondition supporting the implementation and fault recovery mechanisms [0211]
High overall system efficiency by reduced ‘uncoordinated’ system redundancy [0212]
High system availability—no typical system bus bottleneck is blocking the system [0213]
High system reliability [0214]
Perfect hardware prerequisite supporting ‘Firewall’ implementations [0215]
In general, the TCET architecture can be used in the following listed applications as well, however since representing a new type of system architecture, the system is not immediately compatible to de-facto-standards as known for example in today's personal computer scenario. In consequence, existing Operating Systems and applications (Software) would have to be ported and translated: [0216]
Large scale computing systems [0217]
Standard office computing systems (e.g. ‘Personal Computer’) [0218]
Very low end/low cost embedded systems [0219]
Game computers [0220]
FIG. 9 shows, as an example, an overall electronics system as typically realized in today's high-end automobiles. The block diagram displays an TCET ECU networked/corresponding width eight external ECUs. [0221]
The applications provided by this example system are Human-interface functions, Multimedia support, as well as vehicle domain functionality like cabin control functions (light control, climate control, engine and braking system monitor and others). [0222]
The TCET ECU, labeled as Core ECU, is typically providing the main processing functionality within this system scenario, according. [0223]
On the real-time access ports, the TCET ECU is connecting (via ComPro, C[0224] 2) to the vehicle real-time networks, like CAN_1 (e.g. cabin network), CAN_2 (e.g. diagnostic network), CAN_3 (e.g. motor network) and other busses. The information gathered and controlled by this networks is for example engine temperature, oil pressure, brake light is failing and others provided by HW near ECU units.
On the ‘unprotected’ side, the TCET ECU is accessing the system intercommunication link via CAP (C[0225] 4). In this example, this link is distinguished by two areas. The ‘local units’ area is interconnecting ECUs in direct physical neighborhood of the Core-ECU. For cost reason, this type of network is using low cost copper media. The units 1 to 3 are for example: displays, radio system or a telephone.
By the ‘sys-link Xtender’ unit, this local system is extended connecting to remote system units (like CD-ROM player or other for example located in the trunk of the vehicle). The network media connecting the local and the remote units would typically be a optical link. [0226]

Claims

1. Electronic control system for controlling the function of a processing system, especially in an automotive vehicle,

characterized in that

said electronic control system comprises a plurality of main logical control elements, each of which is especially adapted to perform special tasks, whereby each of said control elements is able to communicate with every other control element.

2. Control system as in

claim 1

, wherein four logical control elements are used.

3. Control system as in

claim 1

, wherein said control elements are represented by individual processors.

4. Control system as in

claim 1

, wherein said control elements are represented by specific hardware elements, namely standard μ-Controllers, programmable or firmware-controlled State-Machines and Sequencers or combinatorial asynchronuous or sequential Boolean logic circuits.

5. Control system as in

claim 1

, wherein said control elements are represented by a single CPU.

6. Control system as in

claim 1

, wherein said control elements are represented by software.

7. Control system as in

claim 1

, wherein one of the logic control elements functions as a common access point.

8. Control system as in

claim 2

, wherein said control elements are arranged in a tetrahedron geometry.

9. Control system as in

claim 7

, wherein three of said control elements comprise immediate link ports and one arbitrated link port, connected with the control element functioning as the common access point.

10. Control system as in

claim 9

, wherein the link ports preferably use identical data link protocol and/or the physically representation thereof.

11. Control system as in

claim 1

, wherein control element 1 represents the specific functionality of system support applications, element 2 covers all applications related with real-time networks and direct hardware controls, element 3 exercises all human interface applications and the ECU specific functionalities, and element 4 functions as a network access point connecting to ECU-external extension units and to local area networks (LAN) or wide area networks (WAN).

12. Control system as in

claim 11

, wherein the system support applications are choosen from the group consisting of power management, wake-up and sleep control, system vitality monitor and system fault handling.

13. Control system as in

claim 11

, wherein the direct hardware is choosen from the group consisting of motors, relays and other real-time ECUs.

14. Control system as in

claim 11

, wherein the human interface applications are choosen from the group consisting of physical I/O, visual I/O and voice I/O.

15. Control system as in

claim 9

, wherein the arbitrated link uses the standard bus access technique Collision Sense Multiple Access (CSMA).

16. Use of the control system of any one of the preceding claims in an automotive vehicle.