Structure and Design of Building Automation Systems

Bernd Schrmann University of Kaiserslautern D-67653 Kaiserslautern, Germany e-mail: schuerma@informatik.uni-kl.de

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 rst 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 ofce 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, re alarm, power supply, water supply, TV and other media, garbage disposal, telephone, and also employee management. The task of building automation is the efcient, exible, 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 nd rst 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 eld 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 elds like automotive, avionics, and process automation, there was (and is) need for specialized eld buses which are adapted to the application eld. Some aspects one has to consider for selecting (or dening) 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 dene 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 eld 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 ofce 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/ofces, oors, 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 (gure 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 elds. 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 sufcient 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 no international standard. Nevertheless, it is the direct competitor of EIB in the U.S. Its primary application eld 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 ber 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 eld bus in our list is CAN (Controller Area Network). CAN has been developed for coupling complex controllers and has rstly been used extensively in the automotive area. Later-on the application eld 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 elds. 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 specication was fault tolerance due to the intended application eld(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 dene hierarchical networks as it is the case for EIB and LON. Although we currently nd 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 denes 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 specied as a single bus system with an 11 bit uniform address space. This is sufcient for automation in automotive but not for larger process automation systems or building automation. In a recent extension, CAN 2.0B has been specied with 29 bit identiers 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 oor, or a wing only) it is desirable to split the network in smaller subnets. A simple conguration with two hierarchy levels is shown in gure 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 eld bus, in our case CAN, as backbone, too. Then, we have to extend the at address space to a hierarchical one at the application level (as we stated above, CAN itself does not 6

network controller high-speed backbone room/loor A

controller / bridge, router

CAN

CAN

subnet A1

subnet B1

Figure 2

Hierarchical CAN network

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 oor or other smaller area, then a eld 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 eld bus technology. In addition, communication from one CAN bus segment into another over a LAN makes addressing and routing more complex. The CAN identier of the target node has rstly 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 gure 3 (if we dene hierarchical addresses as we have seen with EIB or LON then bridges are sufcient 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

subnet B2

room/oor B

oor/wing

GAL CS1 CS4 PSEN ALE WR RD Status LEDs EPROM

80C592 Single Chip CPU

RAM

CAN Contr. 1

CANTransc. CAN backbone

data bus

Port 5

CAN Contr. 2

CANTransc.

Figure 3

CAN bridge based on an 8 bit 8051 microprocessor.

address bus A0 A15 CAN subnet

Port 4

the microprocessor bus as an I/O device. The specication 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 ltering 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 specication 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 identier of a SLIO into its physical 4 bit identier 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

DIP

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 nal 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 specication 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 design specication HW/SW codesign (partitioning) implementation spec. building architecture

building automation knowledge

simulator generation simulator prototyping

prototype generation prototype prototype generation

code generation code (SW)

HW synthesis (distributed) HW integration and test

synthesis of OS and communication system system software

HW/SW codesign

Figure 4

Design process of a building automation system. 9

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 rst step of HW/SW codesign is a very important partitioning step. In this step we generate the implementation specication which contains the specication for the hardware selection or hardware generation task as well as the specication of the control software which nally has to run on that hardware. The SDL processes will be partitioned with respect to the specied 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 specication, too. After generating the hardware, software, and system software concurrently, the nal 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 renement 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 gure 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-rene. The capture&simulate approach starts with an informal requirement specication from which designers rst 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 veried 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 specication 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-rene 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-Rene Approach

In the specify-explore-rene approach at the system level the designer rst chooses a technology, he allocates some components which have to be part of the nal system and then he species all requirements the nal system shall fulll. In addition, the designer species 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 specication and the additional constraints. When he/she decides for one of the design alternatives the specication will be rened by adding structural information. With that, the specify-explore-rene approach can be supported by a CAD system that is somehow similar to a blackboard system. As shown in gure 5 all design data like requirement analysis data, specication 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 gure 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 gure 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 gure 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 nd 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 nd a solution in the lower-left 11

performance analysis reliability analysis

verication synthesis

other analysis identication of bottleneck

uniform data representation (abstr. HW/SW model)

generation of design alternatives

simulation runtime [ms] 1200 1000 800 600 400 200 0 20 40 60 80 100 120 cost [$] pure SW solution ( processor)

analysis of design alternatives further constraints: reliability, fault tolerance real time, power consumption size/weight, memory restrictions upgradability, durability user-friendly, recycability short design time ...

Figure 5

Specify - Explore - Rene approach.

corner which is the fastest but also the cheapest possible solution. Note that the diagram in gure 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 gure 5. Besides speed and cost it may be important that the solution is fault tolerant (which is important for our application eld 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-rene 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 proling. 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 nd in the research community (e.g. 12

[2], [3], [4]) and which perform the partitioning step automatically, support the specifyexplore-rene cycle, too. These systems support design processes which are similar to the process shown in gure 6. All data including the system specication 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) prole 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.
specication mostly C but also SDL, Esterel, Statecharts, ... constraints

internal representation

library feedback: analysis results of the former design step

interaction with the designer HW e.g. VHDL

partitioning

SW e.g. C progr.

prole

HLS / processor selection prototyping, co-simulation system integration

compiler

analysis / simulation

Figure 6

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 gure 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 Entry CC

...
MIMOLA Entry Schematic format (ext. syutem) cnvrt analysis analysis

...
Schematic Entry schematic entry

...

format cnvrt

TimberWolf Schematic Entry (ext. system)

Schematic Entry chip synthesis PLAYBASE prototype design database

repartitioning Schematic Entry

Schematic Entry cell synthesis

area Schematic Entry estimation DESIMA design management

Schematic Entry chip planning

Figure 7

Attached to the PLAYOUT kernel we can see several design tools in gure 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 gure 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 gure 7. Those tools comprise the list of all system modeling tools (e.g. 14

...

PLAYOUT design environment.

...

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-rene approach in an ideal manner. Many different tools support the designer within the specication, exploration, and renement phases while analysis tools, simulators but also the PLAYOUT kernel (database and design manager) help the designer in nding 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 nd many tools like compilers and synthesis. At the system level HW/SW codesign generally follows the specify-explore-rene 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 exible 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 protable 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 eld 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 specic applications eld: building automation.

15

5. References
[1] [2] 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, Specication 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. Theiinger, P. Plger, 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]

[3] [4]

[5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]

16