Civil Engineering Reference
In-Depth Information
• It is not really a HLP; it is a meta-HLP, i.e. a protocol for constructing a protocol.
• It is not a communication protocol, but a system control protocol.
• It is designed to maximize the composability of a system.
• It is designed for achieving high performance at low cost throughout the life
cycle of a system.
• It is intended for hard real-time and safety critical systems.
• It is designed to allow a mix of time-triggered, event-triggered and sequential
schedules.
• It is designed to minimize development time of systems and modules by separat-
ing the system design and module design tasks as far as possible.
• It is designed to allow a system to be individually optimized at any time during
its lifetime.
• It is designed to allow changes between modes during run time, e.g. from normal
mode to a limp home mode.
• It is not compliant with the OSI model.
• CK uses a unique vocabulary for essential terms to make them unambiguous.
CK is based on an unorthodox approach to Distributed Embedded Control Systems.
Most CAN systems are based on the seven-layer OSI model, where the different
applications in a network are separated by an independent communication layer.
However, this approach can lead to severe timing and synchronization problems
because the timing of CAN messages is not controlled. A great advantage of CK is
that it allows the system designer to take full control of message transmissions by
scheduling them in time or sequence, as well as having unschedulable messages (as
alarms) to be transmitted when needed. In the approach for CK the whole system
is viewed as a combination of devices, such as joysticks, actuators, sensors, etc.,
all controlled by one imaginary application. This imaginary application is broken
down into a number of real sub-applications, with each sub-application residing in
a module of its own and integrated into the respective device. Sub-applications have
two parts: A local part takes care of everything needed for the device it resides in
and the other part interacts with other devices. In this way, we have two clear lay-
ers: an imaginary system layer and a module layer. The imaginary system layer is
brought to reality by a third “glue” layer that integrates the sub-applications with
each other. This glue layer provides a common application programming interface
(API) that is partly based on a serial communication. Thus, the communication is
not a separate layer as in the OSI model; it is an inherent part of the system, gluing
sub-applications together to run as one common real-time application. The restric-
tions imposed by the serial bus communication make the interfaces between the
respective sub-applications very clean and predictable in time and sequence.
CAN is the serial communication of choice and the basis of the glue layer in
CAN Kingdom. Each module has primitives of the glue layer that are completed by
information sent during a configuration phase. A specific system module containing
all necessary information needed to harmonize each module to the system require-
ments controls this phase. In this way, generic modules can be easily combined into
complex, high-performance systems. In a simple system, the system module can
be disconnected after the setup procedure. However, in more advanced systems,
