Structure and Design of Building Automation Systems
Content
Structure and Design of
Building Automation Systems
Bernd Schürmann
University of Kaiserslautern
D-67653 Kaiserslautern, Germany
e-mail: [email protected]
Abstract
Building automation comprises the control and management of the whole building installation
which is heating, air conditioning, light, security equipment, etc. The overall goal is to reduce
resource consumption, to increase safety and security, as well as to increase the comfort of the
people. To reach this goal we need a comprehensive, large distributed control software that
makes use of the whole equipment.
This paper consists of three parts: We first give a short overview of the application domain
“building automation” to give an impression of the requirements on the control software. We
then describe the environment in which the control software is embedded. In large buildings
this is a huge distributed environment consisting of hierarchical busses which connect plenty
of sensors, actuators, and small processors. Finally, we present our approach of Hardware/Software-Codesign of building automation systems. The functionality of the building control system has to be partitioned onto a large set of distributed processors which interact via a
suitable communication system. The design of the embedded control systems has further to
ensure constraints like maximum reaction times, fault tolerance, and low costs.
1. Introduction
The complexity of the installation of buildings is growing rapidly. This can be seen for small
private houses as well as for large office buildings, plants, and airports. This increasing investment in building installation is due to the effort to reduce the consumption of energy and other
resources as well as for increasing safety, security and the comfort of the people in the building.
Modern microelectronics and microprocessor technology enable “intelligent” control of all
functions like heating, air conditioning, security systems, and much more. While today most of
1
these aspects are controlled individually, in future the partial control systems have to be integrated for further improvement. Even the assignment of service people may be optimized by
specialized programs. Modern building automation systems perform complex control loops as
well as comprehensive supervision, visualization, and optimization functions. The reduction of
resource consumption and the reduction of staff salary due to increased productivity justify the
cost of the building installation (hardware and software).
The Intelligent Building
In case of completely automated buildings we often use the term Intelligent Building. This
means that the knowledge and the function for usage, maintenance, and security of buildings
are represented in computer programs. The microprocessors, on which these programs are running, are connected among themselves but also with the sensors and actuators by suitable data
buses.
We can see many functions of a building which are suitable for automation. A longer but not
complete list of such function contains: heat regulation, air conditioning, climate control, light
control, elevators, access control, security system, fire alarm, power supply, water supply, TV
and other media, garbage disposal, telephone, and also employee management. The task of
building automation is the efficient, flexible, and fault-tolerant control of the whole building
containing all those functions.
Today, most of the automation functions have their own controllers and often their own data
networks, too. Building automation is separated in many islands. Only higher supervision
instances may have knowledge of the state of the whole building. However, this knowledge is
generally not exploited for optimizing the control system. The knowledge is used for the building management level, only. This management level performs central tasks like supervision of
all automation functions which means visualization of the state of the building, statistics, and
eventually energy management and other global optimizations.
The partitioning of building automation into local control functions and a central building
management leads to a hierarchical automation architecture. The separate implementation of
the various automation functions as island solutions has historical reasons. Before the automation age, each function has been considered by a different industry section. Later, those companies considered process automation for their own function, only, without considering the other
functions of a building. Only today, we find first experts for integrating the automation of different functions.
On the other hand, the island approach also has some advantages. A very important aspect of
building automation is fault tolerance. As long as each function and the higher management
level are separated, a malfunction in one component has no effect on other building automation
functions. Even if the overall management function fails the different control functions may
still perform their task stand-alone. This kind of fault tolerance must be met by future building
2
automation architectures.
Our vision of building automation is a virtually central but physically decentralized, distributed architecture. We have one logical control system that combines all sensors and actuators
of the complete installation in a single large, optimized, and intelligent control loop. A complex control algorithm optimizes all automation functions together to improve the solution of
the overall goal stated above: resource reduction and security/comfort increase. The central
control system is then implemented as a distributed program on a variety of microprocessors
and intelligent sensors/actuators which are connected by a large homogeneous data network.
There should be no physical separation between the building control level and the building
management level which requires new fault tolerance approaches.
The remaining part of this paper is structured as follows. In section 2 we describe the most
important part of the building automation hardware, the communication network. We show the
move from dedicated wiring to central bus structures. The description of our hierarchical field
bus approach will complete that section. In the following section 3 we then move to the design
aspects of building automation. Here we describe our idea of designing and implementing the
central control algorithm on the distributed hardware infrastructure. At the end of the paper, in
section 4, we shortly talk about open questions and necessary future works.
2. Communication Systems in Building Automation
First building automation systems (not only) consisted of separated functions. Sensors, actuators, and controllers of such building automation functions have generally been connected by
point-to-point wiring. This kind of wiring was acceptable as long as only few devices had to be
connected over short distances. With increasing automation, however, this wiring structure
became unacceptable. Connecting sensors, actuators, and controllers in building automation
required bus-based data communication. As it was the case for other automation fields like
automotive, avionics, and process automation, there was (and is) need for specialized field
buses which are adapted to the application field. Some aspects one has to consider for selecting
(or defining) a suitable bus system are
• timing constraints: throughput and reaction time
Both are moderate for building automation. Field bus systems generally try to guarantee short reaction times by allowing small data packets only: about 10 bytes compared
to 1000 bytes with Ethernet for example.
• fault tolerance
As stated above, fault tolerance is very important in building automation. On the other
hand, a good system design may define suitable default values and solutions for individual actuators or local subsystems so that individual control function can still work
even if the overall system fails. If this is the case, fault tolerance is not so important for
3
•
•
•
•
the communication system.
electromagnetic shielding
This is not so much a problem for building automation as for process automation or
automotive with powerful motors which may interfere with the data communication
system.
number of bus members
This may become a high value for large buildings.
cost
There is demand for inexpensive wires and bus connectors in building automation.
bus protocol
The bus protocol should be simple to be implementable on inexpensive bus interfaces.
Recently, industry established three major field bus systems in the area of building automation: EIB which is a standard that dominates the European market, LON a very popular defacto standard in the U.S., and CAN which originally has been developed for the automotive
area but which becomes more and more popular in the process automation and building automation, too. All three bus systems will be described shortly in the following subsection.
2.1 EIB, LON, CAN
In Germany, the most frequently installed installation bus, especially in private and office
buildings, is EIB, the European Installation Bus. An EIB network has a hierarchical structure
that generally adapts to the hierarchical structure of the building consisting of rooms/offices,
floors, wings, and so on. An EIB network is divided into several areas which again are divided
in one or more lines. Nodes, i.e. bus members which may be sensors, actors, controllers, or a
combination of them, may not only be connected to the lines at lowest hierarchy level but also
to the “backbone wires” (figure 1). The bus lines at the different hierarchy levels are connected
by couplers which cut the subnets electrically and logically. Similarly to routers the couplers
interpret the addresses of data packets for reducing the net load. Routing in an EIB network is
area
coupler
main line
coupler
line
node
Figure 1
EIB network
4
relatively simple because all nodes only have physical addresses which are also organized hierarchically. The address of each node describes its position in the network. The address consists
of the area number, the line number within the area, and the node number within the line. This
is similar to the internet addressing with IP addresses containing domain, subnet, and node
fields. Nodes are assigned to one ore more groups. Signals are sent to all members of a group.
A maximum sized EIB network consists of 15 areas. Each area has 12 lines each of which
may connect 64 nodes at most. In total, the network can connect up to 11,500 nodes while the
distance between any two nodes must not extend 700 m. The cable is a relatively inexpensive
shielded twisted pair (SDP). Maximum throughput is 9,600 bit/s which is barely sufficient for
today’s control level where controllers, sensors, and actuators communicate with few data
only. For future applications which combine the various functions and the management level
of building automation, this small throughput may become the drawback of EIB.
LON (Local Operating Network) has been developed by Echolon, and therefore it is no
international standard. Nevertheless, it is the direct competitor of EIB in the U.S. Its primary
application field is also building automation and it has the same hierarchical structure as EIB:
network nodes are connected to subnetworks which again are connected to an area. At most
approximately 32,000 nodes are partitioned into 255 subnets of 127 nodes each. So, the topology is similar to EIB. Also, the hierarchical routing and the structure of the node addresses are
similar. Similar to EIB, different nodes in one subnet can be assigned to a logical group with a
special address. A node may belong to up to 15 groups.
Differences can be found at the electrical level. LON supports Twisted Pair with standardized RS-485 interface as well optical fiber for higher data rates. The data rates further depend
on the size of the network. Using STP wires the rates vary between approx. 50 kbit/s if the
communication length is up about 1.5 km and 1.25 Mbit/s for shorter nets up to 300 m.
In contrast to EIB, LON does not support the physical communication layer only. LON also
provides network variables at OSI levels 6 and 7. These are global variables (e.g. temperature
values) provided to all application programs in the whole network. The values of these variables will be updated automatically (and transparently for the application program) by the communication system.
The third field bus in our list is CAN (Controller Area Network). CAN has been developed
for coupling complex controllers and has firstly been used extensively in the automotive area.
Later-on the application field extended to household appliances, medical equipment, and more
general process automation. However, it may also be used as an installation bus in building
automation but until today, in industry, CAN did not yet exceed production lines. Nevertheless,
a big advantage of CAN are the inexpensive bus controllers due to the large numbers of sold
controllers in the various application fields.
The physical layer of CAN is similar to LON. CAN also uses STP and symmetrical RS-485
interface. The differential voltage levels improve the tolerance against electromagnetic inter5
ferences. The data rates are slightly lower than for LON. CAN allows the transmission of up to
10 kbit/s over 1 km and 1 Mbit/s over 40 m. A much more important aspect for the bus specification was fault tolerance due to the intended application field(s) with high electromagnetic
interferences. This is not as important for building automation but was a major reason for
CAN’s success in process automation.
The problem of using CAN in building automation is the fact that CAN is a simple bus only.
CAN does not define hierarchical networks as it is the case for EIB and LON. Although we
currently find more and more couplers for connecting CAN buses to larger networks routing in
CAN networks is much more complicated than in EIB or LON networks. These couplers, provided by some companies, are small microprocessors with two CAN interfaces. The absence
of hierarchical addresses (CAN defines an 11 bit or 29 bit uniform address space. Addresses of
bus nodes are assigned logically but do not describe the positions of the nodes in the network)
requires more or less large translation tables in the bus couplers. These tables are necessary to
reduce the bus load by splitting network segment not only physically but also logically. A prototype implementation of such a coupler that has been developed in our group will be
described below.
In the following subsection 2.2 we describe how we build a hierarchical network based on
CAN buses. Our reason for choosing CAN for building automation are the inexpensive and
very well supported bus controllers. This allows us to implement intelligent sensors and actuators with bus interface easily.
2.2 Hierarchical CAN Bus Systems
Originally, CAN was specified as a single bus system with an 11 bit uniform address space.
This is sufficient for automation in automotive but not for larger process automation systems or
building automation. In a recent extension, CAN 2.0B has been specified with 29 bit identifiers
whose values represent priority values but not topological addresses.
Due to physical restrictions we need a hierarchical network in building automation as it is
the case for EIB or LON (see above). In larger buildings, bus length may easily become several
hundred meters. For achieving high data rates (which will be necessary for implementing powerful control of more than one function) and reducing the bus load (many messages must be
exchanged inside a room, a floor, or a wing only) it is desirable to split the network in smaller
subnets. A simple configuration with two hierarchy levels is shown in figure 2. Here, we have
several subnets which are connected by a (high-speed) backbone.
Generally, all sensors and actuators are connected to the buses at lower/lowest hierarchy
level. The backbone only connects the subnets. Controllers may also be attached to the backbone. The backbone may therefore be implemented by two technologies. One possibility is to
use a field bus, in our case CAN, as backbone, too. Then, we have to extend the flat address
space to a hierarchical one at the application level (as we stated above, CAN itself does not
6
room/floor B
room/flloor A
high-speed backbone
controller /
bridge, router
subnet B2
CAN
subnet B1
Hierarchical
CAN network
subnet A1
CAN
Figure 2
floor/wing
network controller
support hierarchical addresses at the lower communication levels). Alternatively, we can use
simple LAN technology for the backbone. There already exist CAN-LAN gateways as well as
LAN controllers for nearly all microprocessor systems on the market. At a glance, simple LAN
technology, e.g. Ethernet, would be the best choice for the backbone since it can be used for
general data communication, too.
We agree that LAN technology is suitable for bridging large distances, e.g. between two
wings, because separated wings of buildings can be controlled individually and communication is necessary at the management level, only. On the other hand, if we already need a hierarchical solution within a floor or other smaller area, then a field bus as backbone is more
suitable. In this case direct communication between sensors and actuators of different subnets
may be necessary. LAN technology would then prevent real-time communication (more precisely fast reaction times) and other advantages of field bus technology. In addition, communication from one CAN bus segment into another over a LAN makes addressing and routing
more complex. The CAN identifier of the target node has firstly to be converted into a LAN
address by the CAN-to-LAN gateway for routing into the target subnetwork and secondly to be
encoded within the data section of the LAN data packet to be available for addressing within
the target subnet.
In our group we therefore decided to implement a prototype building automation environment based on a hierarchical CAN network. Within the scope of a master thesis we developed
a CAN bridge shown in figure 3 (if we define hierarchical addresses as we have seen with EIB
or LON then bridges are sufficient for data routing). The heart of the bridge is a simple 8 bit
microprocessor with one internal CAN interface. A second CAN interface has been attached to
7
GAL
ALE
80C592
Single Chip CPU
Port 5
RAM
CAN Contr. 1
CANTransc.
address bus A0 – A15
PSEN
EPROM
data bus
DIP
Port 4
WR
Status LEDs
RD
CS1 – CS4
CAN
Contr. 2
CAN backbone
CANTransc.
Figure 3
CAN bridge based on an 8 bit
8051 microprocessor.
CAN subnet
the microprocessor bus as an I/O device. The specification of the bridge was to connect a
1 Mbit/s high-speed backbone (attached to the internal CAN controller) with a slower 125
kbit/s subnet (attached to the external CAN controller). The router is able to forward a message
from the subnet into the backbone (and vice versa) within approx. 50 ms. Since the microprocessor is not very powerful it was necessary that the CAN controllers already perform part of
the address filtering in hardware. This is possible by masking the CAN controllers with special
address masks which reduce the address space a lot. Multicast can then be done in a limited
way only.
In the subnets we also use simple and inexpensive CAN controllers with 125kbit/s interface
and 4 bit free address space only. These controllers, called SLIOs (Serial Linked I/O), determined the subnet specification for the bridge. The limited address space restricts us to 16
SLIOs in one subnet. On the other hand, we want to use more than 16 SLIOs in several subnets. We therefore implemented an address conversion function into the bridge that converts a
global 16 bit/29 bit identifier of a SLIO into its physical 4 bit identifier that has to be unique in
its subnet only.
In the case that CAN controllers are too expensive (and too powerful) for a single sensor/actuator we decided to use simple Dallas sensor circuits which communicate via a primitive Dallas 1-wire bus. Using those circuits we replace the CAN bus at lowest hierarchy level
by the Dallas 1-wire bus. For this case we exchange the external CAN controller of the bridge
8
by a 1-wire busmaster. We implemented this controller by a Xilinx FPGA. Details of this 1wire busmaster are beyond the scope of this paper.
Since we now know the structure of our building automation hardware infrastructure based
on a hierarchical CAN network we now show how the application system can be implemented.
3. HW/SW Codesign of Building Automation Systems
Figure 4 shows an overview of our approach of embedded system design. It shows all steps
from problem description up to the final product integration in a rough diagram. Iterations in
the design process which are typical for such a complex task are neglected to make the process
easily understandable. However, iterations and backtracking may take place at all steps of the
system development process.
The upper part of the diagram shows the requirement analysis and the system design phases.
Using the problem description document, the architectural description of the building under
design, and general information about building automation we perform requirement analysis
and we set up the object structure of the complete control system. The output will be, in our
case, SDL diagrams describing the design specification which are input for the following
HW/SW codesign phase. These SDL diagrams describe hierarchical systems of interacting
independent processes. They should provide maximum possible parallelism which may partly
problem description
building architecture
requirement analysis
& object structure
&SDL diagrams
building automation
knowledge
design specification
prototype generation
simulator
HW/SW codesign
(partitioning)
prototype
prototyping
implementation spec.
prototype generation
code generation
HW synthesis
synthesis of OS and
communication system
code (SW)
(distributed) HW
system software
HW/SW codesign
Figure 4
integration and test
Design process of a building automation system.
9
simulator generation
be sequentialized later-on during the codesign phase. We use this approach because it is much
more easy to sequentialize parallel processes than to search for inherent parallelism in sequential behaviors.
A first step of HW/SW codesign is a very important partitioning step. In this step we generate the implementation specification which contains the specification for the hardware selection or hardware generation task as well as the specification of the control software which
finally has to run on that hardware. The SDL processes will be partitioned with respect to the
specified hardware. If we decide to use specialized operating and communication systems
which are adapted to the considered control system, that system software has to be described in
the implementation specification, too. After generating the hardware, software, and system
software concurrently, the final step will be the system integration and its test.
Many additional constraints have to be met during the whole design process. If we check
those constraints after completing the integration phase of the complete control system, extensive backtracking steps will be the result. However, backtracking and design iterations are
time-consuming and therefore expensive.
In our approach we try to validate the intermediate result after each design step by prototyping to avoid extensive backtracking steps. This prototyping can be done by making all models
and design documents executable. Using a building simulator and partly the actual hardware
infrastructure of the control system the design documents are then validated as far as it is possible for the current design state. In the optimal case this iterative refinement approach reduces
the necessary design iterations and backtracking steps to a minimum.
In this paper, we don’t want to describe this prototyping approach in more detail. This is the
topic of the contribution “Modeling Embedded Digital Controllers”. We restrict ourselves to
the lower part of figure 4 for the rest of this paper. In the following, the HW/SW codesign
phase will be further described.
Shift in Design Methodology
During the almost 30 years of design automation we witnessed three different design methodologies, especially for the hardware design. In temporal order these methodologies are generally called “capture&simulate”, “describe&synthesize”, and “specify-explore-refine”.
• The “capture&simulate” approach starts with an informal requirement specification
from which designers first set up a rough block diagram of the circuit, i.e. of the product to be developed. Each of the functional blocks will then be implemented by a netlist by using graphical schematic entry tools. All design decisions have to be done
“manually” by the designer. After completing the circuit by hand, the circuit will then
be simulated and verified with respect to functionality and timing behavior. This
approach is feasible for small circuits, e.g. circuits at gate level.
• The currently mostly used approach is “describe&synthesize”. The specification and
10
with that the functionality of the circuit is described by a hardware description language (HDL) like e.g. VHDL. The circuit will then automatically be generated by
CAD tools, more exactly by logic or high-level synthesis tools. Circuit synthesis is
state of the art at RT level and pretty well examined at processor level.
• While system design has been done manually until today, research is now looking for
computer aid at system level. Due to the huge design space we have to examine during
HW/SW codesign, there has been no “describe&synthesize” approach at this high
level until today. The overall design decisions of the current “specify-explore-refine“
approach are done manually while CAD tools are mostly used for individual exploration steps. Intermediate steps may be done by the two former approaches “capture&simulate” and “describe&synthesize”.
The Specify-Explore-Refine Approach
In the “specify-explore-refine” approach at the system level the designer first chooses a technology, he allocates some components which have to be part of the final system and then he
specifies all requirements the final system shall fulfill. In addition, the designer specifies all
further constraints. After that, the exploration step takes place. The designer generates design
alternatives and simulates or validates each design alternative with respect to the requirement
specification and the additional constraints. When he/she decides for one of the design alternatives the specification will be refined by adding structural information.
With that, the “specify-explore-refine” approach can be supported by a CAD system that is
somehow similar to a blackboard system. As shown in figure 5 all design data like requirement
analysis data, specification data, and structural information are stored in a central uniform data
representation, i.e. an abstract HW/SW model. All CAD tools like synthesis, analysis, simulation, etc. are placed around that central data repository. A sample list with several such CAD
tools is shown in the upper part of figure 5. Most important at system level are good analysis
and simulation tools.
An example of how complex the design space can be is shown in the lower part of figure 5.
The diagram shows some design solutions of an embedded controller for controlling the volume measurement in the medical area by using supersonic waves [6]. The designer could use
one of three available chip sets, all with different performance and cost values. Furthermore,
the designer could allocate one or more chips from one chip set and he/she could add a standard processor for implementing those parts of the controller in software which are not time
critical. The diagram in figure 5 contains three curves representing the three different chip sets.
The dot in the top-left corner represents pure software solution (i.e. using a standard processor
only) which is the most inexpensive and the slowest solution. In the bottom-right corner we
find the most expensive but fastest solution. All other points in the diagram describe compromises in term of cost or in term of speed. In general, we do not find a solution in the lower-left
11
performance analysis
verification
reliability analysis
synthesis
uniform data representation
(abstr. HW/SW model)
other analysis
generation of
design alternatives
identification of
bottleneck
analysis of
design alternatives
simulation
runtime [ms]
1200
further constraints:
• reliability, fault tolerance
pure SW solution (→ processor)
1000
• real time, power consumption
800
• size/weight, memory restrictions
600
• upgradability, durability
400
• user-friendly, recycability
200
• short design time
0
Figure 5
20 40
60
80 100 120 cost [$]
• ...
“Specify - Explore - Refine” approach.
corner which is the fastest but also the cheapest possible solution.
Note that the diagram in figure 5 already contains 15 different solutions which have to be
evaluated although the diagram considers two aspects of the design space only. The diagram
considers the most important parameters which are speed and cost. However, there may be
much more constraints which must also be met. Several of those constraints are shown in the
lower-right part of figure 5. Besides speed and cost it may be important that the solution is fault
tolerant (which is important for our application field building automation), that the power consumption is low if we design portable devices, or the recyclability has to be considered due to
constraints by law.
The “specify-explore-refine” approach is used for nearly all system designs. Besides the
example shown above, [14] and [15] describe two real designs from GMD (engine control in
automotive and video manipulation in multimedia) and [13] describes the design of a portable
computer as interactive blueprints used by technicians. In all cases the CAD support concentrates on a good data management, interactive representation of design decisions and - what is
most important - comprehensive design validation, simulation, and profiling. The same holds
for nearly all commercial design systems. The HW/SW partitioning step which is a centrals
aspect of HW/SW codesign has mostly to be done manually. Literature therefore often speaks
of HW/SW cosimulation instead of codesign.
However, “real” codesign systems, which we mostly find in the research community (e.g.
12
[2], [3], [4]) and which perform the partitioning step automatically, support the “specifyexplore-refine” cycle, too. These systems support design processes which are similar to the
process shown in figure 6. All data including the system specification and all constraints are
stored in an internal representation. HW/SW partitioning is based on these data. After implementing hardware and software concurrently and integrating all hardware and software components to achieve the overall system, an extensive analysis and simulation phase results in
(new) profile data of the system which are used for feedback and design iterations based on
improved partitioning steps.
A hot topic and very important research topic that is currently evolving in embedded system
design is the compilation task. As we described above, system level design means generating
many different solutions which have to be tested. The designer generally has many different
hardware environments as basis for the same software. He/she therefore needs a compiler with
one frontend but a generic backend which can be adapted to the different (generated) hardware
structures. These compilers are called “retargetable compilers” [12]. The input of such retargetable compilers is not only the source code (as it is for general compilers) but also a description or model of the instruction set and/or structure of the hardware platform.
specification
mostly C
but also SDL, Esterel,
Statecharts, ...
interaction with
constraints
internal
representation
library
feedback: analysis results of
the former design step
partitioning
the designer
HW
e.g. VHDL
SW
e.g. C progr.
profile
compiler
analysis /
simulation
HLS /
processor
selection
→ prototyping,
co-simulation
Figure 6
system integration
General codesign approach.
The PLAYOUT Prototype Design System
Figure 7 gives an overview of the PLAYOUT design system, the prototype system devel13
oped in our group. It has originally been developed for the design of VLSI ASICs. Since its
overall structure is similar to that described in figure 5 it can easily be extended to HW/SW
codesign at system level. The kernel of our PLAYOUT system also is a central design database
and a tightly attached design management component. By interacting with the database the
design manager keeps track of the current design state, the possible design alternatives, and it
is responsible for managing the individual design steps. Design decisions themselves have to
be done by the designer. The PLAYOUT kernel only supports the designer by a convenient
interactive user interface and various analysis tools.
format
SDT
Schematic
Entry
(ext. system) cnvrt
....
Schematic
Entry
partitioning
....
Schematic
CC Entry
...
analysis
analysis
...
...
Schematic entry
Entry
schematic
repartitioning
Schematic
Entry
...
TimberWolf
Schematic
Entry
(ext. system)
Schematic
Entry
chip synthesis
„PLAYBASE“
prototype
design database
area
Schematic Entry
estimation
Figure 7
format
cnvrt
Schematic
Entry
cell synthesis
Schematic
Entry
chip planning
„DESIMA“
design
management
...
format
MIMOLA
Schematic Entry
(ext. syutem) cnvrt
PLAYOUT design environment.
Attached to the PLAYOUT kernel we can see several design tools in figure 7. All tools communicate with the database via an own exchange format which is easily extendable for new
design tasks (as it is necessary for extending PLAYOUT from hardware level to system level).
All design tools in figure 7 which are emphasized by the gray background have been taken
over from our hardware design system. They are still necessary when extending the design
space from processor level to HW/SW system level. Those tools are structural circuit design
tools like module generators and schematic entry, a repartitioner, and physical design tools like
chip planning, cell synthesis, and so on. Some tools have been implemented in our group while
other tools or systems have been developed elsewhere and integrated in PLAYOUT, only (e.g.
MIMOLA from University of Dortmund, TimberWolf from University of Washington).
Additional tools which we need for HW/SW codesign at system level are indicated above
the gray rectangle in figure 7. Those tools comprise the list of all system modeling tools (e.g.
14
the SDT or Statemate system modeling environments), software development tools like compilers, debuggers, and simulators, as well as HW/SW partitioning tools.
With this architecture, PLAYOUT supports the “specify-explore-refine” approach in an
ideal manner. Many different tools support the designer within the specification, exploration,
and refinement phases while analysis tools, simulators but also the PLAYOUT kernel (database and design manager) help the designer in finding and making design decisions.
4. Open Questions and Future Work
Embedded system design, independently of whether in building automation or other process
automation areas, has already been done in academia and industry for quite some time. Nevertheless the design still is a kind of artwork that needs experienced designers. Design automation and CAD support are still in the beginning.
More extensively examined are pure software and pure hardware design. In these areas we
find many tools like compilers and synthesis. At the system level HW/SW codesign generally
follows the “specify-explore-refine” approach. Only few academic institutes try to perform
HW/SW partitioning automatically. The basic hardware architecture used by those institutes
consist of a standard processor and a synthesized coprocessor which exchange data over a
common bus and shared memory. But this architecture cannot be used for the distributed environment of building automation.
Building automation is based on an environment consisting of sensors, actuators, and several (small) controller which are wide-spread over the whole building. Due to cost restrictions,
off-the-shelf hardware should be used as far as possible. Retargetable compilers may be advantageous to be flexible during selection of appropriate controllers for the different tasks.
Due to these hardware restrictions (many inexpensive and distributed components) HW/SW
codesign for building automation goes beyond current HW/SW design systems like Cosyma
[4] and Polis [2]. Hardware synthesis will be necessary and profitable only if we need new
intelligent sensors and actuators. In those cases we can think about implementing part of the
control functionality in these intelligent field devices. In all other cases, partitioning at system
level can be reduced to partitioning the control functions among the various existing controllers.
Although HW/SW codesign for highly distributed systems is a new research topic we are
optimistic to achieve good results (which may be applicable in praxis) due to our restriction to
a very specific applications field: building automation.
15
5. References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
R. Airiau, J.-M. Bergé, V. Olive, “Circuit Synthesis with VHDL”, Kluwer, 1994
F. Balarin, M. Chiodo, A. Jurecska, H. Hsieh, A. L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, E. Sentovich, K. Suzuki, B. Tabbara, “Hardware-Software Co-Design
of Embedded Systems: The Polis Approach”, Kluwer, 1997
G. de Micheli, “Hardware/Software Codesign”, Kluwer, 1996
R. Ernst, J. Henkel, T. Benner, W. Ye, U. Holtmann, D. Herrmann, M. Trawny, “The
COSYMA Environment for Hardware/Software Cosynthesis of Small Embedded Systems”, Microprocessors and MicrosystemsVol. 20, No. 3, 1996
D.D. Gajski, N. Dutt, A. Wu, S. Lin, “High-Level Synthesis: Introduction to Chip and
System Design”, Kluwer, 1992
D.D. Gajski, F. Vahid, S. Narayan, J. Gong, “Specification and Design of Embedded Systems”, Prentice Hall, 1994
D. Harel, M. Politi, “Modeling Reactive Systems with Statecharts: The Statemate
Approach”, i-Logix Inc., 1996
IEEE Design & Test of Computers, special issue “Hardware-Software Codesign”, September 1993
IEEE Micro, special issue “Hardware-Software Codesign”, August 1994
S. Kumar, J.H. Aylor, B.W. Johnson, W.A. Wolf, “The Codesign of Embedded Systems”,
Kluwer Academic Publishers, 1996
W. Lawrenz, “CAN system engineering: from theory to practical applications”,
Springer-Verlag, 1997
P. Marwedel, G. Goossens (ed), “Code Generation for Embedded Processors”, Kluwer
Academic Publishers, 1995
A. Smailagic, D.P. Siewiorek, “A Case Study in Embedded-System Design: The VuMan
2 Wearable Computer”, IEEE Design & Test of Computers, Sept. 1993
M. Theißinger, P. Plöger, H. Veit, u.a. “Untersuchung zum Codesign einer Dieseleinspritzregelung mit CASTLE”, GMD-Studien Nr. 306, Dezember 1996, in German
J. Wilberg, R. Camposano, “VLIW Processor Codesign for Video Processing”, Journal
Design Automation for Embedded Systems, Nr. 2, 1997]
16
Building Automation Systems
Bernd Schürmann
University of Kaiserslautern
D-67653 Kaiserslautern, Germany
e-mail: [email protected]
Abstract
Building automation comprises the control and management of the whole building installation
which is heating, air conditioning, light, security equipment, etc. The overall goal is to reduce
resource consumption, to increase safety and security, as well as to increase the comfort of the
people. To reach this goal we need a comprehensive, large distributed control software that
makes use of the whole equipment.
This paper consists of three parts: We first give a short overview of the application domain
“building automation” to give an impression of the requirements on the control software. We
then describe the environment in which the control software is embedded. In large buildings
this is a huge distributed environment consisting of hierarchical busses which connect plenty
of sensors, actuators, and small processors. Finally, we present our approach of Hardware/Software-Codesign of building automation systems. The functionality of the building control system has to be partitioned onto a large set of distributed processors which interact via a
suitable communication system. The design of the embedded control systems has further to
ensure constraints like maximum reaction times, fault tolerance, and low costs.
1. Introduction
The complexity of the installation of buildings is growing rapidly. This can be seen for small
private houses as well as for large office buildings, plants, and airports. This increasing investment in building installation is due to the effort to reduce the consumption of energy and other
resources as well as for increasing safety, security and the comfort of the people in the building.
Modern microelectronics and microprocessor technology enable “intelligent” control of all
functions like heating, air conditioning, security systems, and much more. While today most of
1
these aspects are controlled individually, in future the partial control systems have to be integrated for further improvement. Even the assignment of service people may be optimized by
specialized programs. Modern building automation systems perform complex control loops as
well as comprehensive supervision, visualization, and optimization functions. The reduction of
resource consumption and the reduction of staff salary due to increased productivity justify the
cost of the building installation (hardware and software).
The Intelligent Building
In case of completely automated buildings we often use the term Intelligent Building. This
means that the knowledge and the function for usage, maintenance, and security of buildings
are represented in computer programs. The microprocessors, on which these programs are running, are connected among themselves but also with the sensors and actuators by suitable data
buses.
We can see many functions of a building which are suitable for automation. A longer but not
complete list of such function contains: heat regulation, air conditioning, climate control, light
control, elevators, access control, security system, fire alarm, power supply, water supply, TV
and other media, garbage disposal, telephone, and also employee management. The task of
building automation is the efficient, flexible, and fault-tolerant control of the whole building
containing all those functions.
Today, most of the automation functions have their own controllers and often their own data
networks, too. Building automation is separated in many islands. Only higher supervision
instances may have knowledge of the state of the whole building. However, this knowledge is
generally not exploited for optimizing the control system. The knowledge is used for the building management level, only. This management level performs central tasks like supervision of
all automation functions which means visualization of the state of the building, statistics, and
eventually energy management and other global optimizations.
The partitioning of building automation into local control functions and a central building
management leads to a hierarchical automation architecture. The separate implementation of
the various automation functions as island solutions has historical reasons. Before the automation age, each function has been considered by a different industry section. Later, those companies considered process automation for their own function, only, without considering the other
functions of a building. Only today, we find first experts for integrating the automation of different functions.
On the other hand, the island approach also has some advantages. A very important aspect of
building automation is fault tolerance. As long as each function and the higher management
level are separated, a malfunction in one component has no effect on other building automation
functions. Even if the overall management function fails the different control functions may
still perform their task stand-alone. This kind of fault tolerance must be met by future building
2
automation architectures.
Our vision of building automation is a virtually central but physically decentralized, distributed architecture. We have one logical control system that combines all sensors and actuators
of the complete installation in a single large, optimized, and intelligent control loop. A complex control algorithm optimizes all automation functions together to improve the solution of
the overall goal stated above: resource reduction and security/comfort increase. The central
control system is then implemented as a distributed program on a variety of microprocessors
and intelligent sensors/actuators which are connected by a large homogeneous data network.
There should be no physical separation between the building control level and the building
management level which requires new fault tolerance approaches.
The remaining part of this paper is structured as follows. In section 2 we describe the most
important part of the building automation hardware, the communication network. We show the
move from dedicated wiring to central bus structures. The description of our hierarchical field
bus approach will complete that section. In the following section 3 we then move to the design
aspects of building automation. Here we describe our idea of designing and implementing the
central control algorithm on the distributed hardware infrastructure. At the end of the paper, in
section 4, we shortly talk about open questions and necessary future works.
2. Communication Systems in Building Automation
First building automation systems (not only) consisted of separated functions. Sensors, actuators, and controllers of such building automation functions have generally been connected by
point-to-point wiring. This kind of wiring was acceptable as long as only few devices had to be
connected over short distances. With increasing automation, however, this wiring structure
became unacceptable. Connecting sensors, actuators, and controllers in building automation
required bus-based data communication. As it was the case for other automation fields like
automotive, avionics, and process automation, there was (and is) need for specialized field
buses which are adapted to the application field. Some aspects one has to consider for selecting
(or defining) a suitable bus system are
• timing constraints: throughput and reaction time
Both are moderate for building automation. Field bus systems generally try to guarantee short reaction times by allowing small data packets only: about 10 bytes compared
to 1000 bytes with Ethernet for example.
• fault tolerance
As stated above, fault tolerance is very important in building automation. On the other
hand, a good system design may define suitable default values and solutions for individual actuators or local subsystems so that individual control function can still work
even if the overall system fails. If this is the case, fault tolerance is not so important for
3
•
•
•
•
the communication system.
electromagnetic shielding
This is not so much a problem for building automation as for process automation or
automotive with powerful motors which may interfere with the data communication
system.
number of bus members
This may become a high value for large buildings.
cost
There is demand for inexpensive wires and bus connectors in building automation.
bus protocol
The bus protocol should be simple to be implementable on inexpensive bus interfaces.
Recently, industry established three major field bus systems in the area of building automation: EIB which is a standard that dominates the European market, LON a very popular defacto standard in the U.S., and CAN which originally has been developed for the automotive
area but which becomes more and more popular in the process automation and building automation, too. All three bus systems will be described shortly in the following subsection.
2.1 EIB, LON, CAN
In Germany, the most frequently installed installation bus, especially in private and office
buildings, is EIB, the European Installation Bus. An EIB network has a hierarchical structure
that generally adapts to the hierarchical structure of the building consisting of rooms/offices,
floors, wings, and so on. An EIB network is divided into several areas which again are divided
in one or more lines. Nodes, i.e. bus members which may be sensors, actors, controllers, or a
combination of them, may not only be connected to the lines at lowest hierarchy level but also
to the “backbone wires” (figure 1). The bus lines at the different hierarchy levels are connected
by couplers which cut the subnets electrically and logically. Similarly to routers the couplers
interpret the addresses of data packets for reducing the net load. Routing in an EIB network is
area
coupler
main line
coupler
line
node
Figure 1
EIB network
4
relatively simple because all nodes only have physical addresses which are also organized hierarchically. The address of each node describes its position in the network. The address consists
of the area number, the line number within the area, and the node number within the line. This
is similar to the internet addressing with IP addresses containing domain, subnet, and node
fields. Nodes are assigned to one ore more groups. Signals are sent to all members of a group.
A maximum sized EIB network consists of 15 areas. Each area has 12 lines each of which
may connect 64 nodes at most. In total, the network can connect up to 11,500 nodes while the
distance between any two nodes must not extend 700 m. The cable is a relatively inexpensive
shielded twisted pair (SDP). Maximum throughput is 9,600 bit/s which is barely sufficient for
today’s control level where controllers, sensors, and actuators communicate with few data
only. For future applications which combine the various functions and the management level
of building automation, this small throughput may become the drawback of EIB.
LON (Local Operating Network) has been developed by Echolon, and therefore it is no
international standard. Nevertheless, it is the direct competitor of EIB in the U.S. Its primary
application field is also building automation and it has the same hierarchical structure as EIB:
network nodes are connected to subnetworks which again are connected to an area. At most
approximately 32,000 nodes are partitioned into 255 subnets of 127 nodes each. So, the topology is similar to EIB. Also, the hierarchical routing and the structure of the node addresses are
similar. Similar to EIB, different nodes in one subnet can be assigned to a logical group with a
special address. A node may belong to up to 15 groups.
Differences can be found at the electrical level. LON supports Twisted Pair with standardized RS-485 interface as well optical fiber for higher data rates. The data rates further depend
on the size of the network. Using STP wires the rates vary between approx. 50 kbit/s if the
communication length is up about 1.5 km and 1.25 Mbit/s for shorter nets up to 300 m.
In contrast to EIB, LON does not support the physical communication layer only. LON also
provides network variables at OSI levels 6 and 7. These are global variables (e.g. temperature
values) provided to all application programs in the whole network. The values of these variables will be updated automatically (and transparently for the application program) by the communication system.
The third field bus in our list is CAN (Controller Area Network). CAN has been developed
for coupling complex controllers and has firstly been used extensively in the automotive area.
Later-on the application field extended to household appliances, medical equipment, and more
general process automation. However, it may also be used as an installation bus in building
automation but until today, in industry, CAN did not yet exceed production lines. Nevertheless,
a big advantage of CAN are the inexpensive bus controllers due to the large numbers of sold
controllers in the various application fields.
The physical layer of CAN is similar to LON. CAN also uses STP and symmetrical RS-485
interface. The differential voltage levels improve the tolerance against electromagnetic inter5
ferences. The data rates are slightly lower than for LON. CAN allows the transmission of up to
10 kbit/s over 1 km and 1 Mbit/s over 40 m. A much more important aspect for the bus specification was fault tolerance due to the intended application field(s) with high electromagnetic
interferences. This is not as important for building automation but was a major reason for
CAN’s success in process automation.
The problem of using CAN in building automation is the fact that CAN is a simple bus only.
CAN does not define hierarchical networks as it is the case for EIB and LON. Although we
currently find more and more couplers for connecting CAN buses to larger networks routing in
CAN networks is much more complicated than in EIB or LON networks. These couplers, provided by some companies, are small microprocessors with two CAN interfaces. The absence
of hierarchical addresses (CAN defines an 11 bit or 29 bit uniform address space. Addresses of
bus nodes are assigned logically but do not describe the positions of the nodes in the network)
requires more or less large translation tables in the bus couplers. These tables are necessary to
reduce the bus load by splitting network segment not only physically but also logically. A prototype implementation of such a coupler that has been developed in our group will be
described below.
In the following subsection 2.2 we describe how we build a hierarchical network based on
CAN buses. Our reason for choosing CAN for building automation are the inexpensive and
very well supported bus controllers. This allows us to implement intelligent sensors and actuators with bus interface easily.
2.2 Hierarchical CAN Bus Systems
Originally, CAN was specified as a single bus system with an 11 bit uniform address space.
This is sufficient for automation in automotive but not for larger process automation systems or
building automation. In a recent extension, CAN 2.0B has been specified with 29 bit identifiers
whose values represent priority values but not topological addresses.
Due to physical restrictions we need a hierarchical network in building automation as it is
the case for EIB or LON (see above). In larger buildings, bus length may easily become several
hundred meters. For achieving high data rates (which will be necessary for implementing powerful control of more than one function) and reducing the bus load (many messages must be
exchanged inside a room, a floor, or a wing only) it is desirable to split the network in smaller
subnets. A simple configuration with two hierarchy levels is shown in figure 2. Here, we have
several subnets which are connected by a (high-speed) backbone.
Generally, all sensors and actuators are connected to the buses at lower/lowest hierarchy
level. The backbone only connects the subnets. Controllers may also be attached to the backbone. The backbone may therefore be implemented by two technologies. One possibility is to
use a field bus, in our case CAN, as backbone, too. Then, we have to extend the flat address
space to a hierarchical one at the application level (as we stated above, CAN itself does not
6
room/floor B
room/flloor A
high-speed backbone
controller /
bridge, router
subnet B2
CAN
subnet B1
Hierarchical
CAN network
subnet A1
CAN
Figure 2
floor/wing
network controller
support hierarchical addresses at the lower communication levels). Alternatively, we can use
simple LAN technology for the backbone. There already exist CAN-LAN gateways as well as
LAN controllers for nearly all microprocessor systems on the market. At a glance, simple LAN
technology, e.g. Ethernet, would be the best choice for the backbone since it can be used for
general data communication, too.
We agree that LAN technology is suitable for bridging large distances, e.g. between two
wings, because separated wings of buildings can be controlled individually and communication is necessary at the management level, only. On the other hand, if we already need a hierarchical solution within a floor or other smaller area, then a field bus as backbone is more
suitable. In this case direct communication between sensors and actuators of different subnets
may be necessary. LAN technology would then prevent real-time communication (more precisely fast reaction times) and other advantages of field bus technology. In addition, communication from one CAN bus segment into another over a LAN makes addressing and routing
more complex. The CAN identifier of the target node has firstly to be converted into a LAN
address by the CAN-to-LAN gateway for routing into the target subnetwork and secondly to be
encoded within the data section of the LAN data packet to be available for addressing within
the target subnet.
In our group we therefore decided to implement a prototype building automation environment based on a hierarchical CAN network. Within the scope of a master thesis we developed
a CAN bridge shown in figure 3 (if we define hierarchical addresses as we have seen with EIB
or LON then bridges are sufficient for data routing). The heart of the bridge is a simple 8 bit
microprocessor with one internal CAN interface. A second CAN interface has been attached to
7
GAL
ALE
80C592
Single Chip CPU
Port 5
RAM
CAN Contr. 1
CANTransc.
address bus A0 – A15
PSEN
EPROM
data bus
DIP
Port 4
WR
Status LEDs
RD
CS1 – CS4
CAN
Contr. 2
CAN backbone
CANTransc.
Figure 3
CAN bridge based on an 8 bit
8051 microprocessor.
CAN subnet
the microprocessor bus as an I/O device. The specification of the bridge was to connect a
1 Mbit/s high-speed backbone (attached to the internal CAN controller) with a slower 125
kbit/s subnet (attached to the external CAN controller). The router is able to forward a message
from the subnet into the backbone (and vice versa) within approx. 50 ms. Since the microprocessor is not very powerful it was necessary that the CAN controllers already perform part of
the address filtering in hardware. This is possible by masking the CAN controllers with special
address masks which reduce the address space a lot. Multicast can then be done in a limited
way only.
In the subnets we also use simple and inexpensive CAN controllers with 125kbit/s interface
and 4 bit free address space only. These controllers, called SLIOs (Serial Linked I/O), determined the subnet specification for the bridge. The limited address space restricts us to 16
SLIOs in one subnet. On the other hand, we want to use more than 16 SLIOs in several subnets. We therefore implemented an address conversion function into the bridge that converts a
global 16 bit/29 bit identifier of a SLIO into its physical 4 bit identifier that has to be unique in
its subnet only.
In the case that CAN controllers are too expensive (and too powerful) for a single sensor/actuator we decided to use simple Dallas sensor circuits which communicate via a primitive Dallas 1-wire bus. Using those circuits we replace the CAN bus at lowest hierarchy level
by the Dallas 1-wire bus. For this case we exchange the external CAN controller of the bridge
8
by a 1-wire busmaster. We implemented this controller by a Xilinx FPGA. Details of this 1wire busmaster are beyond the scope of this paper.
Since we now know the structure of our building automation hardware infrastructure based
on a hierarchical CAN network we now show how the application system can be implemented.
3. HW/SW Codesign of Building Automation Systems
Figure 4 shows an overview of our approach of embedded system design. It shows all steps
from problem description up to the final product integration in a rough diagram. Iterations in
the design process which are typical for such a complex task are neglected to make the process
easily understandable. However, iterations and backtracking may take place at all steps of the
system development process.
The upper part of the diagram shows the requirement analysis and the system design phases.
Using the problem description document, the architectural description of the building under
design, and general information about building automation we perform requirement analysis
and we set up the object structure of the complete control system. The output will be, in our
case, SDL diagrams describing the design specification which are input for the following
HW/SW codesign phase. These SDL diagrams describe hierarchical systems of interacting
independent processes. They should provide maximum possible parallelism which may partly
problem description
building architecture
requirement analysis
& object structure
&SDL diagrams
building automation
knowledge
design specification
prototype generation
simulator
HW/SW codesign
(partitioning)
prototype
prototyping
implementation spec.
prototype generation
code generation
HW synthesis
synthesis of OS and
communication system
code (SW)
(distributed) HW
system software
HW/SW codesign
Figure 4
integration and test
Design process of a building automation system.
9
simulator generation
be sequentialized later-on during the codesign phase. We use this approach because it is much
more easy to sequentialize parallel processes than to search for inherent parallelism in sequential behaviors.
A first step of HW/SW codesign is a very important partitioning step. In this step we generate the implementation specification which contains the specification for the hardware selection or hardware generation task as well as the specification of the control software which
finally has to run on that hardware. The SDL processes will be partitioned with respect to the
specified hardware. If we decide to use specialized operating and communication systems
which are adapted to the considered control system, that system software has to be described in
the implementation specification, too. After generating the hardware, software, and system
software concurrently, the final step will be the system integration and its test.
Many additional constraints have to be met during the whole design process. If we check
those constraints after completing the integration phase of the complete control system, extensive backtracking steps will be the result. However, backtracking and design iterations are
time-consuming and therefore expensive.
In our approach we try to validate the intermediate result after each design step by prototyping to avoid extensive backtracking steps. This prototyping can be done by making all models
and design documents executable. Using a building simulator and partly the actual hardware
infrastructure of the control system the design documents are then validated as far as it is possible for the current design state. In the optimal case this iterative refinement approach reduces
the necessary design iterations and backtracking steps to a minimum.
In this paper, we don’t want to describe this prototyping approach in more detail. This is the
topic of the contribution “Modeling Embedded Digital Controllers”. We restrict ourselves to
the lower part of figure 4 for the rest of this paper. In the following, the HW/SW codesign
phase will be further described.
Shift in Design Methodology
During the almost 30 years of design automation we witnessed three different design methodologies, especially for the hardware design. In temporal order these methodologies are generally called “capture&simulate”, “describe&synthesize”, and “specify-explore-refine”.
• The “capture&simulate” approach starts with an informal requirement specification
from which designers first set up a rough block diagram of the circuit, i.e. of the product to be developed. Each of the functional blocks will then be implemented by a netlist by using graphical schematic entry tools. All design decisions have to be done
“manually” by the designer. After completing the circuit by hand, the circuit will then
be simulated and verified with respect to functionality and timing behavior. This
approach is feasible for small circuits, e.g. circuits at gate level.
• The currently mostly used approach is “describe&synthesize”. The specification and
10
with that the functionality of the circuit is described by a hardware description language (HDL) like e.g. VHDL. The circuit will then automatically be generated by
CAD tools, more exactly by logic or high-level synthesis tools. Circuit synthesis is
state of the art at RT level and pretty well examined at processor level.
• While system design has been done manually until today, research is now looking for
computer aid at system level. Due to the huge design space we have to examine during
HW/SW codesign, there has been no “describe&synthesize” approach at this high
level until today. The overall design decisions of the current “specify-explore-refine“
approach are done manually while CAD tools are mostly used for individual exploration steps. Intermediate steps may be done by the two former approaches “capture&simulate” and “describe&synthesize”.
The Specify-Explore-Refine Approach
In the “specify-explore-refine” approach at the system level the designer first chooses a technology, he allocates some components which have to be part of the final system and then he
specifies all requirements the final system shall fulfill. In addition, the designer specifies all
further constraints. After that, the exploration step takes place. The designer generates design
alternatives and simulates or validates each design alternative with respect to the requirement
specification and the additional constraints. When he/she decides for one of the design alternatives the specification will be refined by adding structural information.
With that, the “specify-explore-refine” approach can be supported by a CAD system that is
somehow similar to a blackboard system. As shown in figure 5 all design data like requirement
analysis data, specification data, and structural information are stored in a central uniform data
representation, i.e. an abstract HW/SW model. All CAD tools like synthesis, analysis, simulation, etc. are placed around that central data repository. A sample list with several such CAD
tools is shown in the upper part of figure 5. Most important at system level are good analysis
and simulation tools.
An example of how complex the design space can be is shown in the lower part of figure 5.
The diagram shows some design solutions of an embedded controller for controlling the volume measurement in the medical area by using supersonic waves [6]. The designer could use
one of three available chip sets, all with different performance and cost values. Furthermore,
the designer could allocate one or more chips from one chip set and he/she could add a standard processor for implementing those parts of the controller in software which are not time
critical. The diagram in figure 5 contains three curves representing the three different chip sets.
The dot in the top-left corner represents pure software solution (i.e. using a standard processor
only) which is the most inexpensive and the slowest solution. In the bottom-right corner we
find the most expensive but fastest solution. All other points in the diagram describe compromises in term of cost or in term of speed. In general, we do not find a solution in the lower-left
11
performance analysis
verification
reliability analysis
synthesis
uniform data representation
(abstr. HW/SW model)
other analysis
generation of
design alternatives
identification of
bottleneck
analysis of
design alternatives
simulation
runtime [ms]
1200
further constraints:
• reliability, fault tolerance
pure SW solution (→ processor)
1000
• real time, power consumption
800
• size/weight, memory restrictions
600
• upgradability, durability
400
• user-friendly, recycability
200
• short design time
0
Figure 5
20 40
60
80 100 120 cost [$]
• ...
“Specify - Explore - Refine” approach.
corner which is the fastest but also the cheapest possible solution.
Note that the diagram in figure 5 already contains 15 different solutions which have to be
evaluated although the diagram considers two aspects of the design space only. The diagram
considers the most important parameters which are speed and cost. However, there may be
much more constraints which must also be met. Several of those constraints are shown in the
lower-right part of figure 5. Besides speed and cost it may be important that the solution is fault
tolerant (which is important for our application field building automation), that the power consumption is low if we design portable devices, or the recyclability has to be considered due to
constraints by law.
The “specify-explore-refine” approach is used for nearly all system designs. Besides the
example shown above, [14] and [15] describe two real designs from GMD (engine control in
automotive and video manipulation in multimedia) and [13] describes the design of a portable
computer as interactive blueprints used by technicians. In all cases the CAD support concentrates on a good data management, interactive representation of design decisions and - what is
most important - comprehensive design validation, simulation, and profiling. The same holds
for nearly all commercial design systems. The HW/SW partitioning step which is a centrals
aspect of HW/SW codesign has mostly to be done manually. Literature therefore often speaks
of HW/SW cosimulation instead of codesign.
However, “real” codesign systems, which we mostly find in the research community (e.g.
12
[2], [3], [4]) and which perform the partitioning step automatically, support the “specifyexplore-refine” cycle, too. These systems support design processes which are similar to the
process shown in figure 6. All data including the system specification and all constraints are
stored in an internal representation. HW/SW partitioning is based on these data. After implementing hardware and software concurrently and integrating all hardware and software components to achieve the overall system, an extensive analysis and simulation phase results in
(new) profile data of the system which are used for feedback and design iterations based on
improved partitioning steps.
A hot topic and very important research topic that is currently evolving in embedded system
design is the compilation task. As we described above, system level design means generating
many different solutions which have to be tested. The designer generally has many different
hardware environments as basis for the same software. He/she therefore needs a compiler with
one frontend but a generic backend which can be adapted to the different (generated) hardware
structures. These compilers are called “retargetable compilers” [12]. The input of such retargetable compilers is not only the source code (as it is for general compilers) but also a description or model of the instruction set and/or structure of the hardware platform.
specification
mostly C
but also SDL, Esterel,
Statecharts, ...
interaction with
constraints
internal
representation
library
feedback: analysis results of
the former design step
partitioning
the designer
HW
e.g. VHDL
SW
e.g. C progr.
profile
compiler
analysis /
simulation
HLS /
processor
selection
→ prototyping,
co-simulation
Figure 6
system integration
General codesign approach.
The PLAYOUT Prototype Design System
Figure 7 gives an overview of the PLAYOUT design system, the prototype system devel13
oped in our group. It has originally been developed for the design of VLSI ASICs. Since its
overall structure is similar to that described in figure 5 it can easily be extended to HW/SW
codesign at system level. The kernel of our PLAYOUT system also is a central design database
and a tightly attached design management component. By interacting with the database the
design manager keeps track of the current design state, the possible design alternatives, and it
is responsible for managing the individual design steps. Design decisions themselves have to
be done by the designer. The PLAYOUT kernel only supports the designer by a convenient
interactive user interface and various analysis tools.
format
SDT
Schematic
Entry
(ext. system) cnvrt
....
Schematic
Entry
partitioning
....
Schematic
CC Entry
...
analysis
analysis
...
...
Schematic entry
Entry
schematic
repartitioning
Schematic
Entry
...
TimberWolf
Schematic
Entry
(ext. system)
Schematic
Entry
chip synthesis
„PLAYBASE“
prototype
design database
area
Schematic Entry
estimation
Figure 7
format
cnvrt
Schematic
Entry
cell synthesis
Schematic
Entry
chip planning
„DESIMA“
design
management
...
format
MIMOLA
Schematic Entry
(ext. syutem) cnvrt
PLAYOUT design environment.
Attached to the PLAYOUT kernel we can see several design tools in figure 7. All tools communicate with the database via an own exchange format which is easily extendable for new
design tasks (as it is necessary for extending PLAYOUT from hardware level to system level).
All design tools in figure 7 which are emphasized by the gray background have been taken
over from our hardware design system. They are still necessary when extending the design
space from processor level to HW/SW system level. Those tools are structural circuit design
tools like module generators and schematic entry, a repartitioner, and physical design tools like
chip planning, cell synthesis, and so on. Some tools have been implemented in our group while
other tools or systems have been developed elsewhere and integrated in PLAYOUT, only (e.g.
MIMOLA from University of Dortmund, TimberWolf from University of Washington).
Additional tools which we need for HW/SW codesign at system level are indicated above
the gray rectangle in figure 7. Those tools comprise the list of all system modeling tools (e.g.
14
the SDT or Statemate system modeling environments), software development tools like compilers, debuggers, and simulators, as well as HW/SW partitioning tools.
With this architecture, PLAYOUT supports the “specify-explore-refine” approach in an
ideal manner. Many different tools support the designer within the specification, exploration,
and refinement phases while analysis tools, simulators but also the PLAYOUT kernel (database and design manager) help the designer in finding and making design decisions.
4. Open Questions and Future Work
Embedded system design, independently of whether in building automation or other process
automation areas, has already been done in academia and industry for quite some time. Nevertheless the design still is a kind of artwork that needs experienced designers. Design automation and CAD support are still in the beginning.
More extensively examined are pure software and pure hardware design. In these areas we
find many tools like compilers and synthesis. At the system level HW/SW codesign generally
follows the “specify-explore-refine” approach. Only few academic institutes try to perform
HW/SW partitioning automatically. The basic hardware architecture used by those institutes
consist of a standard processor and a synthesized coprocessor which exchange data over a
common bus and shared memory. But this architecture cannot be used for the distributed environment of building automation.
Building automation is based on an environment consisting of sensors, actuators, and several (small) controller which are wide-spread over the whole building. Due to cost restrictions,
off-the-shelf hardware should be used as far as possible. Retargetable compilers may be advantageous to be flexible during selection of appropriate controllers for the different tasks.
Due to these hardware restrictions (many inexpensive and distributed components) HW/SW
codesign for building automation goes beyond current HW/SW design systems like Cosyma
[4] and Polis [2]. Hardware synthesis will be necessary and profitable only if we need new
intelligent sensors and actuators. In those cases we can think about implementing part of the
control functionality in these intelligent field devices. In all other cases, partitioning at system
level can be reduced to partitioning the control functions among the various existing controllers.
Although HW/SW codesign for highly distributed systems is a new research topic we are
optimistic to achieve good results (which may be applicable in praxis) due to our restriction to
a very specific applications field: building automation.
15
5. References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
R. Airiau, J.-M. Bergé, V. Olive, “Circuit Synthesis with VHDL”, Kluwer, 1994
F. Balarin, M. Chiodo, A. Jurecska, H. Hsieh, A. L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, E. Sentovich, K. Suzuki, B. Tabbara, “Hardware-Software Co-Design
of Embedded Systems: The Polis Approach”, Kluwer, 1997
G. de Micheli, “Hardware/Software Codesign”, Kluwer, 1996
R. Ernst, J. Henkel, T. Benner, W. Ye, U. Holtmann, D. Herrmann, M. Trawny, “The
COSYMA Environment for Hardware/Software Cosynthesis of Small Embedded Systems”, Microprocessors and MicrosystemsVol. 20, No. 3, 1996
D.D. Gajski, N. Dutt, A. Wu, S. Lin, “High-Level Synthesis: Introduction to Chip and
System Design”, Kluwer, 1992
D.D. Gajski, F. Vahid, S. Narayan, J. Gong, “Specification and Design of Embedded Systems”, Prentice Hall, 1994
D. Harel, M. Politi, “Modeling Reactive Systems with Statecharts: The Statemate
Approach”, i-Logix Inc., 1996
IEEE Design & Test of Computers, special issue “Hardware-Software Codesign”, September 1993
IEEE Micro, special issue “Hardware-Software Codesign”, August 1994
S. Kumar, J.H. Aylor, B.W. Johnson, W.A. Wolf, “The Codesign of Embedded Systems”,
Kluwer Academic Publishers, 1996
W. Lawrenz, “CAN system engineering: from theory to practical applications”,
Springer-Verlag, 1997
P. Marwedel, G. Goossens (ed), “Code Generation for Embedded Processors”, Kluwer
Academic Publishers, 1995
A. Smailagic, D.P. Siewiorek, “A Case Study in Embedded-System Design: The VuMan
2 Wearable Computer”, IEEE Design & Test of Computers, Sept. 1993
M. Theißinger, P. Plöger, H. Veit, u.a. “Untersuchung zum Codesign einer Dieseleinspritzregelung mit CASTLE”, GMD-Studien Nr. 306, Dezember 1996, in German
J. Wilberg, R. Camposano, “VLIW Processor Codesign for Video Processing”, Journal
Design Automation for Embedded Systems, Nr. 2, 1997]
16
