Embedded Control Systems Design/Home and Building Automation

This page was imported and needs to be de-wikified.
Books should use wikilinks rather sparsely, and only to reference technical or esoteric terms that are critical to understanding the content. Most if not all wikilinks should simply be removed. Please remove {{dewikify}} after the page is dewikified.

This application chapter discusses the use of embedded control systems in home and building automation systems, sometimes called domotics and immotics. A short introduction to home automation systems and their components is followed by an analysis of the evolution of embedded systems in domotics.

Home automation is a form of building automation, only on a smaller scale and (most of the time) of a lower complexity degree. Both types of systems try to fill in the specific automationrequirements of private homes and buildings, hereby increasing the comfort and security of the users and improving on overall energy efficiency. Not all home automation systems posses these characteristics, simpler (cheaper) systems only focus on comfort or security.

Home automation systems come from the need of automating processes in the house of e.g. an immobile elderly person, a handicapped person,... Building automation systems originate from the simple fact that it is easier to control lots of systems remotely from one place instead of running around, controlling each of these systems manually. (HVAC and chilled / hot water systems come to mind)

Now that electronics are becoming more affordable and implemented in people's houses, the urge for electronic comfort is increasing by the day. Hence the growth of the domotics market.

Home and building automation systems can perform a magnitude of tasks. Nowadays there is almost no limit to the tasks such an automation system can perform. As long as the task itself is not impossible to perform with current mechanical/electronic systems, the only limit is the customers budget.

Some applications of home automation systems include but are not limited to:

Control of lighting

Control of HVAC

Control of doors, windows, curtains, gates, …

Access to and control of security systems

Access to and control of multimedia systems, home entertainment systems

Since this document discusses embedded control systems in home and building automation systems, it is not necessary to give an accurate view of the tasks than can be completed by such an automation system. More information can be found here: Home automation and building automation.

Home automation systems commonly exist of several components, which are all part of the complete system. Each of these components can perform a function, some components are multifunctional.

Most components functions can be categorized into 3 categories:

Input

Output

Control

Some components can be used for input, output and control. A multimedia terminal for example can be used for:

Input (using keyboard, switches, … )

Output (display, loudspeakers, … )

Control (controlling other components like dimming the lights, closing the curtains, …).

In the early days of home automation, a system could be nothing more than a central switching box with timers and some logic modules, with switches wired throughout the house to be used as input and relays / actuators to be used as output.

At the time of writing this document, there is no simple way of categorizing the components of an automation system into input/output/control, since most components incorporate all three functions. Later on in this document this will be the baseline for an analysis of the evolution of home automation systems.

Output functions are mostly performed by components called actuators. Actuators use a signal from the automation system to change the state of an object in the controlled environment (e.g. switching AC power to the circuit feeding the light bulbs, moving an object).

To get an actuator to do something useful in an automation system, most of the time it has to be equipped with extra mechanical/electric systems. A stepper motor e.g. won’t do much unless it’s attached to something, a fluid control valve for example. The output function is thus being performed by a combination of a basic actuator in conjunction with some additional systems.

Control functions are somewhat different than input/output functions in that their functionality itself is not so easy to describe. Control functions can be a lot of things, including but not limited to:

Control functions are performed by a control unit, but since there are so many different forms of systems and again due to the changing nature of home automation systems in time, it is difficult to describe the system that performs these control functions. Systems performing control functions can be as simple as a few logical gates or as complex as a full-blown mainframe.

Evidently, there is a need for a communication system between all these components. Since the birth of home and building automation systems, a multitude of standards has popped up.

In the early days of home automation systems, communication occurred over simple copper wiring. There was no need for high data speed or interference shielding. At the time of writing a lot more possibilities exist for communication in such systems.

All these communication means have their own characteristics, discussing them falls out of the scope of this document. Which standard uses which communication method can be found on the general Wiki page about Home automation.

First of all a short list of embedded control system design characteristics and their application to the current subject of home/building automation systems. These are the characteristics a design engineer has to keep in mind when designing such an automation system:

High importance characteristics:

Focused functionality: a home/building automation system typically has one fixed set of functionalities, and its design is optimized for this specific set. An example set of functionalities consist of improving user comfort and security while saving energy

Boot-up time: home automation systems are supposed to be in working state at all times. Timers keep ticking, lights need to be switched on/off immediately, …

Safe failure modes: domotics can fail but there should be a provision for safe failure in emergency states such as power spikes, loss of power, break-down of components. When failing a home automation system should give back control to the users of the home without for example closing down the house and switching off all the lights.

Communication: since most recent home/building automation systems consist of a large number of subsystems, there is an inherent need for communication between these subsystems.

Energy consumption: low energy consumption is necessary since the newer energy-friendly home automation systems strive to lower the house’s energy usage (e.g. by planning energy-consuming tasks at night or closing the curtains on time to save on heating fuel)

System adaptibility:

Most recent automation systems require custom installations and settings due to the uniqueness of the house / building. Therefore the installer should be able to choose the necessary components for the current configuration, combine them to a working system and set them up to his/her or the end-user's wishes.

Most recent automation systems are capable of working on a higher abstraction level (see further in this document). Therefore the user should be able to adjust such an automation system, setting up his/her own 'mood settings', room configurations, colour tastes, voice recognition, ... without the help of an installer / customer service.

Medium importance characteristics:

Space constraints: the ideal home/building automation system takes up no space in the home/building it controls, it should be invisible except for the input/output.

Long life time: home automation systems must be in working state as long as possible since costs to replace it are higher than replacement costs for simple appliances (e.g. breaking into wall to insert new cables vs. replacing a coffee machine).

Cost: cost is getting more and more important with rising prices (including heating oil, building materials etc.). So a low-cost home automation system is more attractive. On the higher end of the scale cost is less important since the high-end domotics systems are semi-custom built for that customer and most of the time very expensive.

Temperature and humidity: sensors and/or actuators for outdoor use can be succumbed to high temperature (sunlight) or high humidity (rain). Protection against temperature and humidity is necessary for components for outdoor use and components for use in bathrooms / swimming pools / sauna / …

Shocks and vibrations: components of automation systems must be able to withstand small shocks and vibrations coming from users abuse etc. but most of them are not protected to prolonged exposure to shock / vibrations.

EMC: embedded systems in home/building automation should not be disturbed by (nor disturb themselves) other devices in their environment.

Remote servicing: since more and more of the components in home/building automation systems use a mixed software/hardware setup, there is a need to be able to monitor each component and upgrade the software part of it remotely.

Superior quality: most users expect their home automation systems to work all the time, without bugs or errors. Since quite a large part of today’s home automation components consist of recent electronics in combination with software to control the electronics, the expectancy for perfect quality is not as high as it could be. However for the high-end automation systems there is a correlation between cost and quality expectancy, making build quality more important.

Watchdogs: in case of failure the system needs to reset itself so that the user does not need to interact.

Dependability by redundancy: some application domains request 100% robustness against failure of hardware or software components, which requires these components to be provided multiple times. This, however, is not the case for home/building automation systems. Doing so would eradicate the low cost characteristic.

Since there has been a large evolution in home/building automation systems it follows that there has also been an evolution in the technologies used in these systems.

Home/building automation systems span a few decades already and the available technologies evolved over time. Categorizing home/building automation systems in general is very difficult thanks to the change in used technologies.

Therefore an analysis of these systems during their evolution seems in place. On the whole these automation systems can be said to belong to one of following three categories:

Category 1: Centralized hardware – centralized software

Category 2: Distributed hardware – centralized software

Category 3: Distributed hardware – distributed software

The trend that can be seen in the evolution of home/building automation system is that they evolve from category 1 to 3 throughout their existence.

picture schematically describing the centralized/centralized character

The first category is also the one that occurred most in the early days of home/building automation systems. Due to available technologies (the beginning of the semiconductor era) it seemed logical to have a centralized hardware/software setup. This consisted of 1 rack or machine which contained nearly all the necessary hardware and, if applicable, software parts of the system.

A simple switching box with some timers and logical circuits would be sufficient if provided with e.g. switches as inputs and relays as outputs. Later on, when PLC’s were getting into play, systems got a little more complicated, but it was still of the same centralized type.

An advantage of this type of system is that there is no complex hardware/software involved in the system (no operating system needed), making the system straight-forward to design, implement and maintain.

A disadvantage however is the complexity of the cabling from and to the central machine. When numbers of inputs and outputs go up, so does the number of cables. With larger buildings the lengths (and thus cost) of the cables can become an argument to opt for another complexity of system.

Another disadvantage is the lack of flexibility when using such a system. When using a PLC for example, a flexible program will have to be written or the software code will have to be adapted with each hardware update. The necessity to install new cables for each extra input/output is also not very flexible, it rather makes this type of systems suitable for installation when building or upgrading the house/building but unsuitable for installing when the house/building is already built and finished.

The user abstraction level of this type of systems is rather low. This means that for the simplest of these systems the user directly controls the outputs with one input or a logical combination of inputs, the more complex using multiple inputs and timers to set the outputs. For example a user switches a zone of lighting on or off, sets the house to night mode (close the curtains, switch off all the lights except the one outside by the door, …).

In systems with a higher abstraction level the user could, for example, switch the living room to ‘Romantic mode’ or ‘Movie mode’. These kind of abstractions are difficult to program on the simpler category 1 systems (since they are quite inflexible), going up in system complexity eases the task of implementing higher abstraction levels.

This type of system mostly uses standard electrical wiring (low voltage for the inputs, low/high voltage for the outputs). Since there is no communication between different components of the system other than a voltage difference used for inputs/outputs, there is no need for a specific communication protocol.

picture schematically describing the distributed/centralized character

The second category consists of the type of systems found in most lower to middle class home/building automation systems of today and the high end systems of earlier.

They consist of a central controller (mostly an embedded processor or a PC type controller) which runs specific software on an operating system (specific or generic, depends on the implementation). This central controller is then connected to a field bus or busses, which connect it to its hardware peripherals.

The hardware peripherals can also have an embedded processor, but they do not run an operating system. The software can be found only on the central controller, which uses the field bus to communicate with its peripherals and gather inputs / set outputs.

A big advantage of this type of system is its flexibility software-wise. The central controller can easily be reprogrammed for another setup, new peripheral additions, system upgrades, … Since software only resides on the central controller, only the central controller has to be updated.

The fact that the system complexity is a little higher can be an advantage or a disadvantage, depending on the context (developer(s) experience, manpower, development budget, …). When experience and budget (time-wise and financially) allow, this higher system complexity allows for more variated functionality, higher abstraction levels and higher flexibility. When experience and budget aren’t up to the job, the higher complexity can be a big time-eater in the development process. So in short, design and implementation of this type of system requires more manpower, experience and budget when comparing to a category 1 system.

An advantage is the fact that shorter and less complex cabling can be used. Inputs/outputs for each room can be routed to a room interface module which is connected to the field bus. Only the field bus then connects the interface module and the central controller. This saves some installation trouble and it also simplifies expansion of the room’s inputs/outputs if the interface module allows for expansion.

Another advantage over category 1 systems is the flexibility hardware-wise. As long as the newly added/upgraded hardware peripheral is compatible with the field bus protocol, no extensive hardware changes are necessary. Only the software needs to be updated.

A disadvantage for this type of system is that it is bound to a specific field bus, which means there’s still a cable running through the house/building. This compromises interoperability between different manufacturers, different field bus generations, …

The hardware peripherals are not very sophisticated, they only consist of a hardware layer, no software involved. This is benificient for the robustness of the hardware peripherals but compromises the system’s flexibility.

In comparison with category 1 systems, a higher abstraction level can be achieved. It’s easier to implement on the more powerful central controller, but still the software is quite problem specific and the ‘abstraction levels’ need to be programmed into the software. This does not make for a user-friendly input for these ‘abstraction levels’ since the user needs to update the software of the central controller manually to implement them.

In systems of category 3, if implemented, the user can setup his or her own ‘abstraction levels’ at user interfaces throughout the house, without having to meddle with the central controller’s software. This is not possible for category 2 systems (in a strict sense) because there is no bi-directional communication between central controller and hardware peripherals.

A multitude of field busses have been developed for the sole purpose of serving in home/building automation systems, including e.g. Batibus. Naming all field busses ever used for these systems and describing them is beyond the scope of this document.

Also it would not be correct to list domotic standards here since most of these standards use multiple means of communication, mixing category 2 and 3 communication methods.

picture schematically describing the distributed/distributed character

The third type of systems is found in the newest home/building automation systems and some of the most expensive older systems. Here a total home/building automation system consists of multiple sub-systems of category 1 or 2, linked together using a software and communication layer. Communication between these sub-systems can occur via a lot of different networking technologies (RF, wireless, optical, …).

While systems of category 1 or 2 were synchronous, most category 3 systems work in an asynchronous way, due to every subsystem having its own controller (with or without an operating system).

For example: every room in a house is a sub-system of category 2, controlling the lighting, the curtains, the multi-media content, the temperature, … Every room has its own controller used for setting inputs or outputting music/video/security info/… Each room is controlled by the room’s controller while there are controllers which can control a room’s controller.

For example when going on a vacation, every room has to switch off the power as to save as much energy possible, but it might come in handy to have a light on in a random room every night as to give the impression somebody’s home. The room’s controller must then have some priority scheme to decide which command to listen to.

A disadvantage for this type of system is the high complexity of the total system, requiring a lot of manpower, experience and budget to develop and implement such a system. This includes protocol compatibility, sub-system software and hardware compatibility, multiple products using different software for different functionality, …

An advantage is the multitude of available communication methods and the possibility of mixing them in the total system, making the system very flexible for various installation types and updates at a time after installation completion.

An advantage is the flexibility when updating software since sub-system by sub-system can be updated without shutting down the whole system.

Another advantage is the reliability of the total system. If the controller of one room fails, then only that room would be incontrollable (if it is not controllable from the next room or from a central controller). If there are 2 controllers in 1 room and one fails, then the room would still be functionally accessible through the other controller.

An advantage can also be found in the fact that the system can be highly ‘customized’ to suit the user’s needs due to the widely embedded software and controllers on a higher abstraction level.

With systems of category 3, the highest degree of abstraction can be attained due to their high processing power and extensive software flexibility. The hardware is more of a generic kind while the software makes up for the functionality of the different components.

picture of a high abstraction level interface for home automation systems

A highly user-friendly interface which can control different abstraction layers aids the user greatly to implement his or her custom ‘abstraction levels’. If the user likes soft jazzy music, dimmed lights, the curtains closed, the hearth lit etc. when he’s having a romantic evening, he could program a ‘Romantic’ abstraction program which, when called, closes the curtains, switches off television, puts on some soft jazzy music, dims the lights and lights the hearth.

This type of system is very suitable for high level automation control, but this also means that the software has to be flexible and robust, even more than in categories 2 and 1. This doesn’t get any better since the user will have a lot more interaction with this kind of system than with simpler types of systems.

These systems use a mix of different communication technologies, including twisted pair, electrical wiring, radio frequency, coaxial, optical, …

An overview of these different communication technologies and which standard uses which technology is out of the scope of this document, but information about these can be found on their respective Wikipedia page or on the general home automation page.