-
8/4/2019 10.1.1.26.1332
1/16
1
Structure and Design of
Building Automation Systems
Bernd Schrmann
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 plentyof sensors, actuators, and small processors. Finally, we present our approach of Hard-
ware/Software-Codesign of building automation systems. The functionality of the building con-
trol 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 invest-
ment 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 build-
ing.
Modern microelectronics and microprocessor technology enable intelligent control of all
functions like heating, air conditioning, security systems, and much more. While today most of
-
8/4/2019 10.1.1.26.1332
2/16
2
these aspects are controlled individually, in future the partial control systems have to be inte-
grated 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 run-
ning, 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 isgenerally not exploited for optimizing the control system. The knowledge is used for the build-
ing 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 automa-
tion age, each function has been considered by a different industry section. Later, those compa-nies 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 dif-
ferent 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
-
8/4/2019 10.1.1.26.1332
3/16
3
automation architectures.
Our vision of building automation is a virtually central but physically decentralized, distrib-
uted 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 com-
plex 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 fieldbus 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, actu-ators, 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 guaran-
tee 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 indi-
vidual 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
-
8/4/2019 10.1.1.26.1332
4/16
4
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 automa-
tion: EIB which is a standard that dominates the European market, LON a very popular de-
facto 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 auto-
mation, 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
main line
coupler
coupler
line
node Figure 1 EIB network
-
8/4/2019 10.1.1.26.1332
5/16
5
relatively simple because all nodes only have physical addresses which are also organized hier-
archically. 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
todays 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 nointernational 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 topol-
ogy 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 standard-
ized 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 varia-
bles will be updated automatically (and transparently for the application program) by the com-
munication 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 inter-
-
8/4/2019 10.1.1.26.1332
6/16
6
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 specifi-
cation 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
CANs 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, pro-
vided 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 toreduce the bus load by splitting network segment not only physically but also logically. A pro-
totype 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 actua-
tors with bus interface easily.
2.2 Hierarchical CAN Bus SystemsOriginally, 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 pow-
erful control of more than one function) and reducing the bus load (many messages must beexchanged 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 back-
bone. 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
-
8/4/2019 10.1.1.26.1332
7/16
7
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 communica-
tion is necessary at the management level, only. On the other hand, if we already need a hierar-
chical 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 pre-
cisely fast reaction times) and other advantages of field bus technology. In addition, communi-
cation 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 environ-
ment 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
network controller
high-speed backbone
room/flloorA
room/floorB
floor/wing
subnetA
1
subnetB
2
subnetB
1
CAN
controller /bridge, router
CAN
Figure 2 Hierarchical
CAN network
-
8/4/2019 10.1.1.26.1332
8/16
8
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 microproc-
essor 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), deter-
mined 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 sub-
nets. 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 sen-
sor/actuator we decided to use simple Dallas sensor circuits which communicate via a primi-
tive 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
80C592
CAN Contr. 1
W
RRD
PSEN
A
LE
GAL
CAN
EPROM
RAM
Contr. 2CAN-
Transc.
CAN-Transc.
DIP
CS1 CS4
Port 4
Port 5
databus
addressbusA0A15
CAN backbone
CAN subnet
Status LEDs
Single Chip CPU
Figure 3 CAN bridge based on an 8 bit
8051 microprocessor.
-
8/4/2019 10.1.1.26.1332
9/16
9
by a 1-wire busmaster. We implemented this controller by a Xilinx FPGA. Details of this 1-
wire 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
requirement analysis& object structure&SDL diagrams
HW/SW codesign
design specification
implementation spec.
code generation
code (SW)
building architecture
building automation
simulator generation
prototype generation
prototype generation
HW synthesissynthesis of OS and
communication system
(distributed) HW system software
prototype
simulator
(partitioning)
integration and test
prototyping
HW/SW codesign
Figure 4 Design process of a building automation system.
knowledge
-
8/4/2019 10.1.1.26.1332
10/16
10
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 sequen-
tial behaviors.
A first step of HW/SW codesign is a very important partitioning step. In this step we gener-
ate the implementation specification which contains the specification for the hardware selec-
tion 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, exten-sive 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 prototyp-
ing 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 pos-
sible 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 dont 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 meth-
odologies, especially for the hardware design. In temporal order these methodologies are gen-
erally 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 prod-
uct to be developed. Each of the functional blocks will then be implemented by a net-
list 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
-
8/4/2019 10.1.1.26.1332
11/16
11
with that the functionality of the circuit is described by a hardware description lan-
guage (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 explora-
tion steps. Intermediate steps may be done by the two former approaches cap-
ture&simulate and describe&synthesize.
The Specify-Explore-Refine Approach
In the specify-explore-refine approach at the system level the designer first chooses a tech-
nology, 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 alterna-
tives 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 requirementanalysis 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, simula-
tion, 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 vol-
ume measurement in the medical area by using supersonic waves [6]. The designer could useone 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 stand-
ard 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 compro-
mises in term of cost or in term of speed. In general, we do not find a solution in the lower-left
-
8/4/2019 10.1.1.26.1332
12/16
12
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 beevaluated 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 con-
sumption 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 concen-
trates 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.
1200
1000
800
600
400
2000 20 40 60 80 100 120
pure SW solution ( processor)
runtime [ms]
cost [$]
performance analysis
reliability analysis
verification
synthesis
simulation
other analysis
identification ofbottleneck
generation ofdesign alternatives
analysis ofdesign alternatives
further constraints:
reliability, fault tolerance
real time, power consumption
size/weight, memory restrictions
upgradability, durability
user-friendly, recycability
short design time
...
uniform data representation
(abstr. HW/SW model)
Figure 5 Specify - Explore - Refine approach.
-
8/4/2019 10.1.1.26.1332
13/16
13
[2], [3], [4]) and which perform the partitioning step automatically, support the specify-
explore-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 imple-
menting hardware and software concurrently and integrating all hardware and software com-
ponents 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) hardwarestructures. These compilers are called retargetable compilers [12]. The input of such retarg-
etable compilers is not only the source code (as it is for general compilers) but also a descrip-
tion or model of the instruction set and/or structure of the hardware platform.
The PLAYOUT Prototype Design System
Figure 7 gives an overview of the PLAYOUT design system, the prototype system devel-
library
interaction with
the designer
mostly Cbut also SDL, Esterel,
prototyping,
co-simulation
Statecharts, ...
feedback: analysis results ofthe former design step
specification constraints
system integration
partitioning
HLS /compiler
analysis /
simulationprocessorselection
internalrepresentation
HWe.g. VHDL
SWe.g. C progr. profile
Figure 6 General codesign approach.
-
8/4/2019 10.1.1.26.1332
14/16
14
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.
Attached to the PLAYOUT kernel we can see several design tools in figure 7. All tools com-
municate 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.
Schematic Entry Schematic Entry
Schematic Entry
Schematic Entry
Schematic EntrySchematic Entry
Schematic Entry
Schematic Entry
PLAYBASEprototype
schematic entry
repartitioning
area
chip planning
cell synthesis
chip synthesis
MIMOLA(ext. syutem)TimberWolf(ext. system)formatcnvrt
formatcnvrt
estimationDESIMA
...
...
design database
Schematic EntrySDT(ext. system)
formatcnvrt
Schematic EntryCC
analysis
analysis
. . .
. . . . . . . .
...
..
.
designmanagement
Schematic Entrypartitioning
Figure 7 PLAYOUT design environment.
-
8/4/2019 10.1.1.26.1332
15/16
15
the SDT or Statemate system modeling environments), software development tools like com-
pilers, 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 (data-
base 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. Never-
theless the design still is a kind of artwork that needs experienced designers. Design automa-
tion 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 envi-
ronment of building automation.
Building automation is based on an environment consisting of sensors, actuators, and sev-eral (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 advan-
tageous 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 control-
lers.
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.
-
8/4/2019 10.1.1.26.1332
16/16
16
5. References
[1] R. Airiau, J.-M. Berg, V. Olive, Circuit Synthesis with VHDL, Kluwer, 1994[2] F. Balarin, M. Chiodo, A. Jurecska, H. Hsieh, A. L. Lavagno, C. Passerone, A. Sangio-
vanni-Vincentelli, E. Sentovich, K. Suzuki, B. Tabbara, Hardware-Software Co-Design
of Embedded Systems: The Polis Approach, Kluwer, 1997[3] G. de Micheli, Hardware/Software Codesign, Kluwer, 1996[4] R. Ernst, J. Henkel, T. Benner, W. Ye, U. Holtmann, D. Herrmann, M. Trawny, The
COSYMA Environment for Hardware/Software Cosynthesis of Small Embedded Sys-tems, Microprocessors and MicrosystemsVol. 20, No. 3, 1996
[5] D.D. Gajski, N. Dutt, A. Wu, S. Lin, High-Level Synthesis: Introduction to Chip andSystem Design, Kluwer, 1992
[6] D.D. Gajski, F. Vahid, S. Narayan, J. Gong, Specification and Design of Embedded Sys-tems, Prentice Hall, 1994
[7] D. Harel, M. Politi, Modeling Reactive Systems with Statecharts: The StatemateApproach, i-Logix Inc., 1996
[8] IEEE Design & Test of Computers, special issue Hardware-Software Codesign, Sep-tember 1993
[9] IEEE Micro, special issue Hardware-Software Codesign, August 1994[10] S. Kumar, J.H. Aylor, B.W. Johnson, W.A. Wolf, The Codesign of Embedded Systems,
Kluwer Academic Publishers, 1996[11] W. Lawrenz, CAN system engineering: from theory to practical applications,
Springer-Verlag, 1997[12] P. Marwedel, G. Goossens (ed), Code Generation for Embedded Processors, Kluwer
Academic Publishers, 1995[13] A. Smailagic, D.P. Siewiorek, A Case Study in Embedded-System Design: The VuMan
2 Wearable Computer, IEEE Design & Test of Computers, Sept. 1993[14] M. Theiinger, P. Plger, H. Veit, u.a. Untersuchung zum Codesign einer Dieseleinsp-
ritzregelung mit CASTLE, GMD-Studien Nr. 306, Dezember 1996, in German[15] J. Wilberg, R. Camposano, VLIW Processor Codesign for Video Processing, Journal
Design Automation for Embedded Systems, Nr. 2, 1997]