text:
Horticulture/Hyalophora cecropia

The caterpillars of the Cecropia Moth feed on a wide range of trees and shrubs. The adult is one of the largest moths found in North America, and females with wingspans that are 75 mm or more have been documented. It is found throughout the Eastern part of the continent, and as far west as the Rocky Mountains and north into the maritime provinces of Canada. The larvae of these moths are most commonly found on Maple trees, but they have been known to feed on Wild Cherry and Birch trees among many others.

Description
Caterpillars are dark-colored and hairy, adults a large moth.

Symptoms and Signs
Foliar damage may be severe if large numbers are present.

Ecology
The life cycle of the moth is much like any other saturniidae species. It lays oval-shaped, light brown eggs on the leaves of the host plant. When the eggs hatch, small black and hairy caterpillars emerge (first instar), and eat their eggshells.Sometimes the newly hatched caterpillars have yellow bristles, which darken in a few minutes. As the caterpillars age, they molt 5 times. The second instar is yellow-green with black spots and spiny orange, yellow and blue knobs. The third and fourth instars have smaller spines, and are similar to each other. The fifth instar is a whitish color with bright yellow, blue and red knobs. The caterpillars feed heavily on their host plant and can grow up to five inches long. They then spin cocoons of brown silk, usually wrapped in leaves of the host plant. They then pupate inside the two-layered cocoon. There is only one brood per year, the cocoon overwintering and emerging in spring. When the adults eclose, they have to pump fluid into their wings to extend them. The females emit pheromones at night, which the male can detect with its large, bushy antennae. Males can fly for miles in order to reach a female. The moths mate, and the female spends the remainder of her life laying eggs, while the male may mate several more times. Because the adult moths do not have mouth parts they are unable to eat. As a result, the lifespan for an adult Cecropia moth is generally only 7 to 10 days in the wild, perhaps a little longer or shorter, depending on how much movement the moth makes. For instance, if temperatures are cooler, the moth may remain mostly inactive, which will increase its life. In captivity, this lifespan can be extended to about a month by placing the moth in the fridge directly after it hatches and its wings are dry. (Those who intentionally rear the moths may find this necessary to synchronize mating.)

Differentiating between genders of this species is very easy. The most obvious difference is the plumose antennae. Males will have a very bushy antenna while females will have a moderately less bushy antenna. Another difference is that the females will be slightly larger in the abdomen due to carrying eggs. Male's abdomens are also more angular than the female's abdomens which are more rounded.

Host plants

 * ../Acer/
 * ../Alnus/
 * ../Betula/
 * ../Cornus/
 * ../Fraxinus/ (Ash)
 * ../Juglans/
 * ../Malus/
 * ../Prunus/
 * ../Quercus/ (Oak)
 * ../Salix/
 * ../Syringa/ (Lilac)
 * ../Viburnum/

title: Horticulture/Hyalophora cecropia


text:
Field Guide/Birds/Haliaeetus leucocephalus

|

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Template:Embedded Control Systems Design/Page

''This template is the general TOC template for the Embedded Control Systems Design wikibook. This template will appear on the main page of the book, and will appear at the top of every page, so it should be kept short.''


text:
Template:Embedded Control Systems Design/Nav

This template is a bottom-of-the-page navigation template for the Embedded Control Systems Design book. The optional first and second arguments are the previous and next page links, respectively.


text:
Embedded Control Systems Design

Preface
This is a textbook at the level of university Master's or graduate students in Engineering (Mechatronics, Mechanics, Electrical/Electronics, Computer Science, Systems Engineering), that explains how to design motion control systems, that is, computer-controlled machines with important moving parts, such as robots, machine tools, cars, buses, airplanes, ships, satellites, telescopes, etc.

The emphasis of the book lies on the design of embedded systems, and much less on the technical details in the systems. (Such details are often covered already in the many Wikipedia articles about the systems' components.) In other words, the book focuses on the systems level thinking that the engineer should do when designing a new embedded application (or redesigning/improving already existing systems). In many places, the book provides a motivated list of things to think of, do's and don'ts and best practices in the design of a system from individual components. The book also tries to bring some structure and classification into the tremendously large variety of embedded systems and their design process: designing a new vending machine brings very different challenges than the design of an automated luggage handling system in a large airport, or than the development of a new generation of football playing robots.

Readers should learn from this book what design criteria (technical, economical, social, etc.) are relevant for specific embedded systems, and what trade-offs are appropriate in different categories of embedded systems. In addition, the book should help readers to estimate the complexity of the system they want to develop, and to identify where this complexity comes from in their specific application. Coping with system-level complexity is a major non-functional requirement behind all embedded systems design and development, since it is the key factor that defines how many resources (time, people, hardware, software,…) will be needed to bring the project to a successful end.

At the moment, this book focuses mainly on motion machines only, where the control is needed to make the machine move in a specified and safe way. So, its scope currently does not include other embedded control systems, such as process or temperature control, video and audio signal processing, telephony, etc. Future enhancements in these directions are certainly welcome, although motion control systems typically offer extra design challenges with respect to the mentioned consumer electronics kind of embedded systems—in that they have to cope with the real physical world and not just with the digital, man-made world—so their design aspects are typically a superset of what is found in consumer electronics.

Motion control systems involve software control components, but also computer-readable models to represent the physical world, sensors (partly hardware, partly software) to measure that physical world, actuators (partly hardware, partly software) to induce changes in the world, and planners (pure software) to precalculate which actions the control system should take in order to reach a desired state.

Embedded can mean many different things (see a later chapter for a list of meanings), but a common characteristic is that the system's complexity—including all its configuration and control components and activities—are not made visible to the user of the systems, but remain hidden behind a user friendly interface that gives only access to the (virtual) model of the embedded system.

This example of an embedded system is used to introduce the most generic concepts of an embedded system, and to motivate the relevance of the later chapters in this book.

Table of Contents
Design: Digital hardware: Software:
 * Design criteria
 * The design process
 * Categories of system complexity
 * A design example NEW
 * A design example OLD
 * Model-driven engineering
 * Process control vs system control
 * What if things go wrong?
 * Hostile Environment
 * Failure modes and prevention
 * Learning from failure
 * Processors
 * Hardware peripherals
 * Field busses
 * Operating systems
 * Real Time Operating systems
 * Software toolchain
 * Design Patterns
 * Coordination Modelling
 * Finite State Machines and Petri Nets
 * Asynchronous activities
 * The four fundamental "concerns" of system design

Applications:
 * Automotive
 * Aviation
 * Robotics
 * Team of RoboCup robots
 * DARPA Challenge
 * Home and Building Automation

Glossary

Licensing

Authors
The initial version of this Wikibook was created by Herman Bruyninckx, together with the students of the course Embedded Control Systems. René van de Molengraft, from the TU Eindhoven, provided valuable contributions during the second year of this course.

Acknowledgements
This Wikibook's layout was inspired by the excellent example of the Control Systems book.

title: Embedded Control Systems Design


text:
Embedded Control Systems Design/Licensing

License
The text of this Wikibook is released under the terms of the GNU Free Documentation License version 1.2. The particular version of that license that is being used can be found at:

 * http://en.wikibooks.org/wiki/Wikibooks:GNU_Free_Documentation_License


text:
Embedded Control Systems Design/Hardware peripherals

This chapter looks at the hardware components (except the processor architectures, discussed in another chapter) that occur in the embedded control systems this book focuses on. More and more, the components discussed in this chapter are not pure hardware anymore, but become embedded systems in themselves, with a growing amount of software functionalities.

The focus is not on the technical details of how this hardware works, but on the information that the systems design engineer needs to make appropriate choices.

 * Buses (electrical, EMC, protocols)
 * AD/DA
 * Digital IO (input, output)
 * PWM (Pulse Width Modulation)
 * Motor amplifier
 * Encoders, resolvers, Hall sensor

I/O modules
In most embedded systems a lot of different types of hardware are all connected to each other. This connection is usually done either mechanically or by using a voltage (sometimes also current) signal over a cable. Typical embedded systems tend to have a lot of different cables with signals, coming from different locations, but going to the same controller. These controllers, on the other hand, only have a few I/O ports. I/O modules have a large number of (mostly digital) inputs and outputs, depending on the type. Communication between the I/O module and the controller occurs through one connection over which both the inputs and the outputs are sent. The I/O module doesn't change the signals on this connection, it only edits them (in a reversible way) such that they can be sent using only one connection. Depending on the type of I/O module, the signals should first go through a ADC/DAC, before being passed on to the I/O module.

The I/O module and the controller typically communicate over a "twisted pair" of wires. The other kinds of connections, and the technical details of the signaling protocol, are outside the scope of this book. If you want more details, see Embedded Control Systems Design/Field busses, Robotics: Computer Control: The Interface: Networks, and the serial communications bookshelf.

Analog-to-digital converters
Analog-to-digital converters (or ADCs) convert an analog input signal (generally a voltage signal) to a digital number. This is a crucial step in hardware interfacing. The practical choice of a converter depends on the desired resolution (mostly 6-24 bits). ADCs are usually preceded by a sample and hold circuit, which samples the input voltage (at the sampling rate) defined by the clock signal and then holds that value for a short time.

Several sampling errors may occur, but can be easily avoided by looking up the device's specifications. Quantization noise is caused by the finite resolution of the ADC. It is an unavoidable kind of noise, but can be reduced to almost any level by using a higher resolution. Thus the signal-to-noise (quantisation noise at least) ratio depends entirely on the resolution.

A second common error is aliasing. Aliasing is due to the finite sampling rate of the sample and hold circuit. If high frequency content is present in the signal (and there always is high frequency noise, for example) then the ADC can not deal with this correctly. When aliasing occurs, this high frequency content, which one might expect to be cut off, will alter the low frequency (and thus desired) content of the signal. In principle, aliasing is avoided when the sampling frequency is higher than the Nyquist frequency (twice the bandwidth of the input signal). To avoid influence by high frequency noise, and to make the ADC more robust, the input signal can also be low-pass filtered before the conversion takes place.

Digital-to-analog converters
Digital-to-analog conversion is a lot like analog-to-digital conversion.

Bandwidth restrictions are determined by the maximum switching speed, and thus the maximum speed at which a digital signal can be processed. These restrictions are entirely due to the nature of the circuit, and cannot be altered. The DAC output is usually a piecewise constant function (zero-order hold). The output value is determined by the digital input and the clock signal. It is held during a clock period, which leads to sharp corners, and thus high-frequency content. The DAC is followed by a low-pass filter.

Digital-to-digital converters
Digital-to-digital conversion is another possibility. With or without getting a clock signal supplied from the controller, small converters can perform a lot of simple operations on digital signals. Changing the bit depth or sample rate are among the possibilities. Whether or not there is a need for a separate wire to the controller for the clock signal depends on the type of operation, and also on the line code. Not having to draw a wire to every digital to digital converter in the system can be quite an advantage. Manchester code for example allows for easy extraction of the clock signal, and can thus be used in digital to digital converters that perform virtually any type of operation. This type of coding (or supplying a clock signal) can be used to perform complex calculations and operations far beyond a simple conversion.

Sensors
Sensors measure the system outputs and present them as inputs to the controller. Often the signal that a sensor generates is too weak, or needs to be modified before it can be transmitted. Effects to be taken into consideration are the in-and output impedances, the linearity of the sensors and the amplifiers, limiting the influence of cable length and other disturbances, etc. Different types of circuitry have been built to deal with these issues. A lot of sensors are bundled with this equipment, often in the same housing. Commercial packages are also available that contain the required devices to hook up to the sensor. These (mostly) electronic devices are mostly made out of operational amplifiers, transistors and RLC circuitry. Comparators, high, low and band-pass filters, source-followers and all kinds of amplifiers are made out of these components.

Rotary encoders
There are two types of rotary encoders: absolute and incremental encoders.

 Absolute rotary encoders

An absolute encoder measures the angular displacement. Its output is a digital signal. The resolution is restricted and determines the accuracy of the complete embedded control system. This encoder can be directly connected to the controller (because of its digital output). Analog versions, such as potentiometers, output an analog signal and thus require an ADC between their output and the controller.

 Incremental rotary rotary encoders

These encoders measure the relative angular displacement. The resolution is, as always, restricted. They output a pulse each time a certain angular displacement takes place. The resulting signal is analog, and has a DC-component. The output is unclocked, which means the sample frequency is not predefined. The rotational speed is measured by the distance between the output pulses. An additional counter that counts the pulses and generates a digital output signal is needed. Several (more expensive) encoders come with this extra piece of hardware built-in. They are as easily connected to the controller as encoders of the absolute type.

Both types of rotary encoders require a feeding signal, on which the output amplitude depends. A digital output signal is relatively insensitive to noise, which means a small amplitude will do the trick.

Resolvers
Resolvers do exactly the same as absolute digital encoders, but output an analog signal.

Tachometers (Hall effect sensors)
A Hall effect sensor is a type of tachometer, used for measuring angular speed. Both the output voltage and frequency are proportional to the angular velocity. It thus produces an analog output signal, more or less like that of incremental encoders.

Other types of tachometers include, for instance, a simple DC-generator, which generates a voltage, proportional to the motor angular velocity, across its main leads.

Proximity sensors
Proximity sensors allow the user to measure the distance to or the presence of an object. Proximity sensor work in a lot of different ways.

Types of sensors

 * Ultrasonic
 * Magnetic
 * Capacitive
 * Radar
 * Sonar
 * Reflective
 * Laser
 * Chemical

Filters
Hardware filters are used to reject noise from a measured signal. Most common are low-pass, high-pass, band-pass and band-stop filters. Filtering obviously only improves the signal-to-noise ratio when the frequency range of the signal differs from that of the noise.

Electrical motor drives
Commercial motor drives are easily configured. A drive can be analog or digital. A software version that runs on the controller's microprocessor is another possibility. There is always need for a module that converts the feeding signal according to the (small) input signal. Commercial drives have these built-in. Several types of these modules exist: pulse width modulators, choppers. These modules make use of thyristor/transistor switches. In the past, thyristors were more widely used, but now transistors (MOSFET/IGBT) are more popular (in low and medium power applications, that is). Thyristor circuits are still frequently used in more powerful applications (in the order of several megawatts), though. E.g.: wind turbines.

The feeding signal may need to be transformed and converted to DC, or shifted in phase, before it is presented to the motor itself.

The start-up of alternate current induction motors leads to a large current peak. This is never the case in normal use, but it might cause problems after a sudden power shut-down. A special start-up device that is switched off when a certain speed is reached, can resolve this possible problem. It may also be considered within the control system itself. The hardware then remains unchanged. Both the input signal and the feeding signal can be filtered to avoid excessive motor noise.

Stepper motors
Stepper motors are often used in positioning systems. The controller sends the desired number of steps to the motor, in which transistor switches are turned on or off in the appropriate order.

Pneumatics and hydraulics
Pneumatic and hydraulic circuits make use of fluids (resp. gasses and liquids) under pressure. These can be present outside of the control system and fed to it. The pump or compressor can also be a part of the embedded system itself. It is then controlled by the controller. Pneumatic and hydraulic circuits consist out of valves that are driven by a mechanism, an electrical current (solenoid valve) or another pneumatic/hydraulic circuit.

 Mechanism driven valves

Pneumatic/hydraulic valves can be driven by a mechanism or a cam-follower system. The mechanism's purely mechanical structure forms the base of a self-controlling scheme. There is little interaction with the controller. The rotational speed of the cam, or a given movement of a branch in the mechanism can be controlled, but the shape of the cam or the mechanism determines the movements of the valves. E.g.: a pneumatic Finite State Machine. The dynamics are restricted by the bandwidth of the spring (in a cam-follower system) and/or the valves themselves (depending on the type).

 Solenoid valves

Solenoid valves can also be used. A fast response, and thus, a large force, is often desired. This leads to large currents. A certain feeding signal is required. This is taken care of by a power circuit with, among many other devices, a current transformer in it. The currents used are large, but the power is not. These circuits are thus different from the ones used in motor drives, where the power consumption is much higher. The dynamics are restricted by the bandwidth of the valves, which is a lot lower than that of the electrical components.

When dealing with high pressures and large flows, several cascaded valves are used. The first one is then driven electrically or mechanically, and then, in its turn, uses the fluid under pressure to drive the next one.

 Driving of the valves

Most of the time, the valve blocks are driven by the central controller, through busses and substations. This is especially the case in larger, industrial systems. Such a hierarchical system is quite clear and allows for the design of very complex structures. There is also the possibility of a real mini-ECS: a controller with 'built-in' valve block. This last solution is compact and works on its own. E.g.: the anti-lock braking system (ABS) in cars.

Practical aspects of hardware interfacing
In order to clearly decouple the useful data from noise, good interfacing is necessary. When cabling is done improperly, electrical noise from the nearby environment can easily be introduced in the circuit. Therefore much attention is needed when making interconnections. In this text, the reader can get a feeling with some common problems about interfacing. At the end, there is a section with some general tips.

Interference noise due to a common impedance
If two circuits have a current path in common, that common path could couple signals of those circuits due to its impedance. This often happens when several circuits use one single path to return current to their power supplies.

A current transient in a digital circuit (when switching logic state) will briefly shift the “ground” reference for the analog circuits.This problem is more important in analog circuits, because of the absence of "noise immunity". Digital systems are -upon a certain level- less sensitive for these effects.

Interference noise due to capacitive or electrostatic coupling
Between any two conductors in a system, there exists a capacitance if the space between them is filled with a dielectric insulator. If the receiving circuit has a large resistive impedance, the related noise signal is affected by the noise signal of the source. This effect is more important at high frequencies. To avoid this electrostatic coupling, the best method is to use an electrostatic shield. In this way the entire circuit is enclosed by a metal screen. From the principle of the 'Faraday cage' follows that the influence of external voltages will be zero inside the shield. A problem is that there will be a stray capacitance from this shield to every conductor within. This reduces its effectiveness. It is clear that this problem will not occur when the digital and analog grounds are kept separate.

Interference noise due to inductive coupling
Two conductors which are close together may have a significant mutual inductance between them. An alternating current in the power circuit then induces a series mode interference voltage in the input circuit. This inductance depends on the geometry of the two circuits, namely on the overlapping length and separation. Inductive coupling will occur even if the measurement circuit is completely isolated from earth. To twist the conductors is the simplest way to reduce the effects of inductive coupling to an external interference. This arrangement is commonly known as twisted pairs. The magnitude of the interference voltage induced in a given loop is proportional to the area of the loop and the rate of change of the external magnetic field. The sign of the induced voltage depends on the orientation of the conductors. In the ideal case of both loops having the same area and experiencing the same magnetic fields, there is a zero resultant induced voltage.

Input section isolation
Isolation amplifying is often used in combination with sensors, because sensors are often weak and sensitive components. An isolation amplifier has a fixed differential gain over a wide range of frequencies, high input impedance, and low output impedance. In addition to that, an isolation amplifier's input is separated from its output and power supply. This way the sensitive and weak input component is secured. Often used techniques for isolation are electromagnetic isolation and optical isolation.

Electromagnetic isolation
An electromagnetic isolation couples an amplified signal between circuits through an air-core transformer. The signal is first modulated on a higher frequency. The air-core transformer blocks the low frequency components (like the DC and 50 Hz power supply). After the signal is transmitted through the transformer, it is demodulated and amplified again. In addition a second transformer can be used to supply the first circuit of power, this way no batteries are needed.

Optical isolation
When optical isolation is used, the transmitted signal is first modulated and then send by a solid-state photo emitter to the photo detector of the second circuit. This way, both circuits are completely electrically decoupled. But this approach requires a battery to be included in the emitting circuit.

Tips and tricks

 * Since mutual inductances and coupling capacitances between measurement and power circuits are inversely proportional to the distance between them, this distance should be as large as possible.
 * Every current that comes from a power source must go back to that power source
 * Every conductor has a finite resistance and impedance, this means that a 'ground' conductor could contain a DC shift and voltage spikes.
 * Check your power supply for voltage spikes with an oscilloscope while the circuit is running.
 * Circuit boards can have a 'ground plane', use it as a electromagnetic shield and not as a conductor to return current.
 * The power supply should be heavily wired to minimize voltage drops.
 * Use capacitors (from 1 to 100 microF) between the power supply conductors and their ground return conductors. Hereby the supply voltage is stabilized for external interference (50 Hz to 1MHZ) and short voltage drops.
 * Use Mylar capacitors across voltage supplies of digital circuits to minimize the effect of short surges of current. Put them also across analog chips that have to be protected form these surges.


text:
Embedded Control Systems Design/Field busses

This chapter looks at the inter-system communication components that occur in the embedded motion systems this book is focusing on.

 * Serial lines
 * Controller Area Network (CAN)
 * Profibus
 * Realtime ethernet (RTnet, EtherCat, ProfiNet...)
 * Devicenet
 * Inter-Integrated Circuit (I2C)
 * Serial Peripheral Interface (SPI)
 * Firewire

Description
A field bus is a part of a system which provides the communication between several components in that system (for example an actuator or a sensor). A bus is a cable with an interface on the two ends. A bus system is a collective noun for all buses, this means that there is a distinguish between:

 * Factory buses (or a factory network)
 * CPU buses
 * Field busses

Factory buses
A factory bus supports the management. The data of consequence for planning, logistic, quality, etc. will be sent over this network. A factory bus has been developed especially for the connection between several computers (for example: PCL, VME, etc.).

CPU buses
See the chapter about processors

Field buses
Three communication types exist for field buses, namely serial, parallel and wireless buses. The difference between serial and parallel field buses is principally the quantity of data that can be sent in one cycle. For a serial bus the process of sending data is one bit at one time. This is in contrast to parallel communications, where all the bits of each symbol are sent together. Wireless field busses are nowadays still in development. Because of this, the use of wireless field buses is limited in control systems.

Why not use the same network everywhere?
Networks such as TCP/IP and Novell have already been on the market for a long time. Much software has been developed for it, and the paediatrics diseases are already solved. Field buses are still “young” networks which are aimed, in contrast to standard networks, to transport small quantities of information. Field busses need less hardware than standard networks. Because of this, they can be incorporated in the smallest sensors and actuators. Field bus applications secure special requirements to the hardware, for example intrinsic safe, voltage supply over the network, very high protection against electric jamming, galvanic separation, control at several places, etc.

OSI model
The operation of the network program can be described by the OSI layer model. The OSI, or Open System Interconnection, model defines a network frame for implementing protocols in 7 layers. Control is passed from one layer to the next, starting at the application layer in one station, proceeding to the bottom layer, over the channel to the next station and back up the hierarchy.

In each of these layers there are certain rules. Two computer systems that want to make contact with each other, must keep themself to these rules. Otherwise there will be misunderstandings and the communication between both will go wrong.

Transport:

Layer 1: Physical
In this layer is described which sort of cable (serial/parallel/wireless) with which bit rate is used. This layer conveys the bit stream through the network at the electrical and mechanical level. Fast Ethernet and RS232 are protocols with physical layer components.

Layer 2: Data link
This layer fixes how and at which moment a message from a computer to another computer can be sent over the same cable. Also defining the addresses and the format of the messages belongs to the agreements of this layer. The data link layer is divided into two sub layers: The Media Access Control (MAC) layer and the Logical Link Control (LLC) layer. The MAC sub layer controls how a computer on the network gains access to the data and permission to transmit it. The LLC layer controls frame synchronization, flow control and error checking.

Layer 3: Network
This layer provides switching and routing technologies, creating logical paths, known as virtual circuits for transmitting data from node to node. If several networks are put together it is necessary to make agreements: -How does the general addressing happen and on how is the route chosen that the message must follow?

Layer 4: Transport
This layer provides transparent transfer of data between end-systems, or hosts, and is responsible for end-to-end error recovery and flow control. In this way we obtain a reliable network connection. It ensures complete data transfer.

Application (control systems):

Layer 5: Session
This layer establishes, manages and terminates connections between applications. There are three kinds of sessions in the OSI-model: - ‘one way’: the information will be sent in one direction. - ‘two way simultaneously’: both participants can send and receive at the same time (full duplex). - ‘two ways alternate’: both sides can various send and receive (half duplex).

Layer 6: Presentation
This layer provides independence of differences in data representation (e.g., encryption) by translating from application to network format, and vice versa (for example: from ASCII to EBCDIC).

Layer 7: Application
This layer specifies which applications are available to the user. Everything at this layer is application specific. The user programs are situated in this layer with which you can read files on another computer, run a process, etc.

Typical usages of field buses at the application levels
There are several typical usages of field buses, the differences are mainly in the way they handle information. The different types in control systems are:

This type of field bus acts as a multiplexer. The data bits are offered to the network and further transported to the outputs elsewhere in the network. The master can send a task to the slave via the bus. The slave processes this task and gives an answer. Slaves can’t communicate mutually. A field bus with several masters. A client gives a task to the server. These will carry out the task first and answer afterwards. A station can be both client and server at the same time and so they can send several tasks at the same time. A field bus with several masters where each consumer station is interested in a certain piece of data, while the producer station provides the information to the consumer that wants to subscribe to the producer data.
 * Remote I/O (central controllers, distributed sensors, machine tools with CAN I/O):
 * Master/slave (master controller, distributed slave controllers)
 * Client/server :
 * Consumer/producer:

Field bus protocol
The field bus interface encodes the commands or the state of an in- or output to digital information which is arranged for transport over the cable.

Properties of field buses

 * Short response time
 * Large reliability
 * Cheap wiring
 * Open standards
 * Simple protocols
 * Low price per connection

Response time:

In real time: deterministic response time (for example CAN)

-very short response time: For the link PLC - periphery Examples: Profibus DP, CAN and Interbus-S.

-average response time: For the link PLC - supervision system Example: Profibus FMS

Wiring for field busses:

The trend is as follows:

 * parallel -> serial -> wireless:

-previous coax (Ethernet cable)

-often RS485

advantages: cheap, easy to install

disadvantage: no high speeds

-also glass fiber

advantage: large distances possible

Open standard

-why:

To make communication possible between heterogeneous systems from different vendors that exists for different OSI layers

-Examples:

DIN 19245 (Profibus), IEEE 1118 (Bitbus) ISO/DIS 11519-1 AND ISO/DIS 11898 (CAN)

-protocols in hardware or software -applicable in devices -not arranged for link of heterogeneous devices -Example: CAN
 * field bus with layer 1 and layer 2

-more complex protocols in software -arranged for link of heterogeneous apparatuses -Example: Profibus-FMS
 * field bus with layer 1, layer 2 and layer 7

Topology
The construction of a network that is built by some field buses can take several physical forms. Such a form is called a topology of a network. Some examples of different topologies are:
 * Star
 * Line
 * Tree
 * Mono-master
 * Multi-master

Advantages of field buses

 * Only a few cables necessary
 * No problems with 4-20 mA conversion (direct communication with PLC or PC.)
 * More intelligence possible in equipment
 * Simple to extend without extra wiring
 * Maintenance and jamming can be searched through the network
 * Digital technique

Disadvantages of field buses

 * There is not yet a standardization of the user interface
 * Sometimes you must contact several manufacturers for support when you have got a problem

Aspects to consider when choosing a field bus

 * The maximum bus length (see overview)
 * Number of clients
 * Data rate
 * Topology
 * Price
 * The time (difficulty) to add/remove a client
 * The maximum cycle time
 * Compatibility between the different field buses
 * Stability of the system
 * Applicability for communication between controllers, PC’s, and/or intelligent equipment
 * Availability of interface cards for PC’s
 * Maximum number of repeaters
 * Maximum number of nodes without using repeaters
 * Maximum number of nodes with use of repeaters
 * Maximum data in one message
 * Maximum number of masters

The most used different field buses

 * Interbus
 * Profibus
 * CAN
 * Ethernet
 * EtherCAT
 * AS-Interface
 * DeviceNet

Overview of the most used bus systems
Bus systems have been developed mostly to be used in a certain scope. In the table below an overview is given along with the specifications of the different bus systems.


text:
Talk:Blender 3D: Noob to Pro/Modeling a volcano

I was wondering, in part of the tutorial when you tell us to subdivide the plane, do you mean for us to subdivide it 5 - 8 time or did you mean to say 15 - 18 times? When I tried 5 - 8 times my volcano did not look like what you had in the picture. When I tried to work with it it did not work very well. Is this an error or is 5 - 8 times what you ment?

-jfireball66

Hi, I was thinking of continuing this tutorial, however I wanted to see if anyone will continue to complete this, or if I have a "go ahead" on this project. If I recieve no resistance by this Monday (March 26th 2007) then I shall attempt to finish this tutorial.

-Spiffy

I think this page needs serious rebuilding. I think using a method similar to 'mountains out of molehills' would be much better than sculpt mode. I think sculpt mode would be a little much for a newbie. I'm going to go ahead and start to work on it that way. Hobo Joe 21:27, 13 June 2007 (UTC)

I started rewriting this tutorial, it will be finished in some days. Morrolan (talk) 15:41, 27 August 2009 (UTC)

Ok, Tut is now in a acceptabe state so I will link it to the main page. There are a little bit too much images, I know, but I think for a newbie tutorial this is ok. As soon as I'm better with particle-systems I will add a new section, how to add real magma. If someone could search for misspellings and incorrect sentences this would be a big help for me. Morrolan (talk) 17:37, 31 August 2009 (UTC)

I've edited some of the tutorial for spelling and clarity. I will probably do a bit more work on it in that direction, and may also rewrite the texture section with a quick realism increase. For magma, I would recommend a fluid simulation, although the volcano is too complex to use fluid sim on (too many vertices). I'll see about writing that. Illusionist (talk) 23:26, 1 September 2009 (UTC)

Thank you for correcting my tutorial. :) I wil probably add some smoke to our volcano in the next days. Morrolan (talk) 16:12, 5 September 2009 (UTC)

I think too many things are being assumed for the user. the texture setting was not previously covered and took time for me to figure out based on an image where it was. "Enter Edit-mode and subdivide [w-subdivide multi] it about 50 to 80 times." where the heck is "w-subdivide multi"? the shape of the cone inside the volcano also affect lighting tremendously. Dracozny (talk) 21:53, 13 October 2009 (PDT)

Perhaps you're right. The texture-section is crap, I know, I'll see about rewritng or deleting it.

The lighting isn't really good but for a tutorial for "Noobs" its ok I think. ;) If you want, feel free to improve it.

[w-subdivide] is probably a bit misleading, I'll correct it. Morrolan (talk) 11:35, 18 October 2009 (UTC)

Hi, absolute noob here. I was working my way through the tutorial and came close to crashing the program. I'm pretty sure I had too many subdivides which is what brought me here. As a beginer, it is best to tell me how many times to press the button. I also scaled the plain though it didn't tell me to. I'm not sure if that was right or not but it was part of the directions for the last project. I disagree it needs more info on how to start the project. Maybe just a warning that this tutorial assumes information learned in pervious tutorials like many of them do. Just my two very noobish cents.

I'm going through the book from the beginning. This chapter has the first mention of lighting as far as I can remember. As such, you should tell the user how to add a lamp. You've simple said: add a lamp (spot). I have no idea where I go to add a lamp. We also have not yet learned to manipulate the camera or render. Chances are that the camera is not taking in the whole scene if and you won't see the crater if it is still set to its default position. Some of us are total noobs here.
 * A little more detail in the lighting please **

Oh, that's bad, thank you for informing me about these things. Sorry I didn't read it sooner, but I'm a little bit short on time at the moment. I'll try explain something a little bit clearer if I find some time. (hope in the next few days) Morrolan (talk) 10:10, 24 January 2010 (UTC)

This is much harder than the previous tutorial pages, it implies a bit of knowledge that noobs wont know (i'm a noob, took me a bit to even add a light) and skips alot of stuff like textures and resizing the spot light -AdamK117

Please Answer ASAP, I need to know how to change the size of the circle from the OKEY and then grab without a mouse wheel. I have a laptop mouse and can't complete the tutorial.

That's bad, I actually have no idea on how to work with blender without a mouse wheel, sorry. Perhaps there exists a solution somewhere in the internet, you might find one. Wish you luck. Morrolan (talk) 16:30, 16 June 2010 (UTC)

I beleve I read that you can set the mouse in the control panel to emulate a 3 buttin mouse, by pressing the left and right button at the same time Pearts (talk) 01:40, 27 July 2010 (UTC)

Hi, You can also use the "Page Up" and "Page Down" keys to increase and decrease the circle of influence or the "O Key"

Niyambhushan (talk) 04:41, 20 September 2010 (UTC)niyam
 * nor value at .50 makes no sense. i pushed the pedal down to 50 and got a stunning-looking volcano. try it.**

Volcano Chapter
The whole lighting issue around the magma needs to be more clear, there seems to be conflicting info in the chapter. Each method for lighting the magma needs to be spelled out better and needs to include images that help explain the method.

The materials section needs a translation into 2.5 as the whole materials/textures thing is handled quite differently.

Cheers,

John

Hopefully this is fixed now. Each suggestion was basically recommending a different lamp type (spot, area, etc), so I got rid of the narrative forms and made a list of instructions. I tried incorporating all of the edits, but I left out the user who mentioned SpotSi since I couldn't figure out what that meant.

The materials section has been updated to 2.6.x, but as I am learning 3D modeling for the first time as I go through this tutorial, this section is most likely uninformed / incomplete. SgtBursk (discuss • contribs) 15:01, 22 April 2012 (UTC)

Vandalism
I saw something that struck me as out of place, the sentence was: "We are going to model a volcano using the proportional edit fallOUT 3 tool." I checked the revision history and falloff had become fallOUT 3 with the most recent change http://en.wikibooks.org/w/index.php?title=Blender_3D:_Noob_to_Pro/Modeling_a_volcano&oldid=2169051. I changed it back and it is pending review. I am pretty new here so if I have made a mistake, I am sorry go ahead and revert Lxxxv (discuss • contribs) 18:21, 19 September 2011 (UTC)


text:
Embedded Control Systems Design/Processors

Processor technology involves the architecture of the computation engine used to implement a system’s desired functionality. All devices we know have processors embedded in it (microwave, cars ...). Choosing the right embedded processor is critical to perform the wanted operations.

=Trends= Nowadays hardware is more and more like software. It can easily be programmed and integrated with other components by an end-user. One simple example is a FPGA which has many more components than it should have so in that way it can be programmed for various applications. It can also be used as an interface for the communication of several hardware components, for instance the integration of a DSP and a hybrid CPU on a mobile phone chip.

Another important trend is a modular design. This means that hardware components are designed as separate parts and can be put together in one device. In this way the device is only programmed for the control and communication of the different components. This has the following advantages:

 * Components can easily be replaced when broken
 * Adding new functions (upgrading) is very simple
 * A small step towards standardization

In the domain of mechatronics standardization is not yet that common. Electronics however is some kind of a pioneer because we can find there many examples of standardization: VHDL, standard components like adders, multiplexers, registers, memory … One simple example here is National Instruments. As time evolves this standardization will also be needed in the mechanical world.

Specific branches
In automotive there is a trend towards centralization. This is because designers have noticed in the past that there were too many parts that required their own controller. So now they are trying to use as few as possible CPU’s. The design is thus more and more focused on the communication busses between the several components which are controlled by only a few CPU’s.

In aviation the requirements are very different. First of all safety is very important. In this way standardization and certification becomes very important. One simple example is the fact that in aviation they only use certified hardware. They still use a Pentium II because this is proven technology.

=Choice of hardware= When one reached the moment at which a choice has to be made about the processor technology, one can choose between 5 categories of processors, each with its own advantages and disadvantages:
 * General purpose processor: usable for several applications, low price, short design time but low performance, high energy consumption and large dimensions
 * Single purpose processor: good performance, small, less energy consumption but more difficult design, more expensive, less flexible
 * ASIP: intermediate solution between single and general purpose processor
 * PLD: low design cost, fast product development, available in large numbers but more energy consumption than ASIP. Some examples are: PLA, FPGA
 * PLC: usable in several working conditions, more standardised but not suited for complex calculations, relative expensive

Besides the choice of processor the designer also has to look for the right communication and storage technology. One example of robust storage technology are solid state hard disks. They are resistant against vibrations, magnetic fields and dirt so they can be used in several working conditions. Examples of communication technology are given by USB, Firewire, CAN-Bus, Ethernet ...

Processor technology involves the architecture of the computation engine used to implement a system’s desired functionality. Most devices we know have processors embedded in it (microwave, cars…). Choosing the right embedded processor is critical to perform the wanted operations. The choice of a processor in a design process can take place on 2 moments. Either you choose a processor in the beginning of the design when you only had a peak on your specifications, this means that throughout the next stages of your design you will need to adapt the wanted functionalities to the processor possibilities. This is the case for instance when you have a fixed budget for the processor, choose the one with the highest possibilities which fits the budget. Or you make the decision at the end of the project, so you know all the necessary functions you want to implement and you can choose a processor type which fits your situation exactly. If possible you must always choose the processor which you have the most experience with to minimise design time and avoid problems. Minimising design time equals less design cost and faster time-to-market.

First we will make an overview of some terms and concepts you should keep in mind when choosing a processor. Then we will look at the different types of processor technology available for the moment and take a peak at the available processors today. And in a third part of this chapter we’ll discuss the programmable logic controller (PLC).

In the text there will be references to interesting articles,sites and links where you can find a clear explanation and a broader view about the subject. In the text they are shown as numbers which refer to a site shown in the reference list. A list of all the references is at the bottom of this chapter.

=Terms, questions=

Performance/speed of a processor
This means the number of clock cycles per second. It determines the number of instructions performed each second. If your processor demands more than processortechnologie can offer, a single processor will not do it anymore. Then it's time to think of a dual-core processor. This will not only double the computational load, but provides flexibility in how software is architedted across the cores, which can even result in reducing power consumption versus a single core running at twice the frequency.

compatible
All hardware selected should be able to communicate with each other. The environment in which the processor has to work can be damaging, so precautions must be taken to avoid unexpected failures.
 * electronic compatibility
 * environmental compatibility
 * Connection is realised by busses

Input/Output
For this you should take a look in Hardware Peripherals

fixed-point/ floating-point device
These are 2 categories of processor computation arithmetic. In general:

Fixed-point:
 * faster
 * more power-conscious
 * cost-sensitive

Floating-point: refers to the granularity with which a fraction can be defined refers to the ratio between the largest and smallest numbers that can be represented in a numeric format
 * high precision
 * dynamic range

memory

 * Cache: Is used by the processor to reduce the time needed to communicate with the (main) memory.
 * Memory address
 * RAM (random access memory)
 * ROM (read only memory)

Are my system needs changing in time
Example: changes for user interface features
 * Yes : then a programmable solution will probably required ( DSP, MCU, FPGA)
 * No : an ASIC might be suitable

life time
required lifetime depends on wanted lifetime of the system, willingness to replace the controller or desire to reuse the controller in other systems

how do I develop on the processor
If you use a good, easy development tool you will increase productivity and decrease development/debug time. This is also dependent of the experienced personnel you have (which are more expensive) and the experience your company has with certain processor types. Of course, when you use code that is written in a common known language it can be easily ported to a new processor and increases the possibility of expanding and rewriting the program.

power consumption
A device can get his power from the electric net or can work on a battery. This restriction (battery) usually involves a tradeoff between performance and power efficiency. Choosing a system with a battery we need to take in account the weight of the battery, time between recharge and safety.

Real-Time Aspects

 * Interrupts and interrupt vectors
 * Support for ‘atomic operations’ ~ mutex (=mutual exclusion) such as Test and Set and Compare and Swap
 * Granularity
 * Privilege levels and CPU modes
 * For the most common processortypes:
 * Microprocessor: When a microprocessor is selected together with an embedded operating system, the operating system is the cause of real-time operations not being straight-forward.
 * Microcontroller: Being a very simple microprocessor, real-time operations are difficult.
 * DSP: When real-time is important such as in signal processing (audio, video…) the DSP will perform the best.
 * FPGA: An FPGA can be configured in such a way that it performs completely like a microprocessor or completely like a DSP. So real-time performance is depending on whether a DSP-like configuration is chosen.
 * PLC: A PLC gets his input from the sensors, evaluates these and makes changes (output), thus it acts as a real-time system

operating system
An operating systems manages the system: managing and processing I/O, memory management, controlling simultaneous processes. If so, make sure your processor supports the OS you chose.

-> An interesting link with a longer explanation about some topics:

=types of processor technology= In this part we will discuss the general processor types, their characteristics and examples

Interesting links for choosing the right processortype for your application:

general purpose processor
The system designer only needs to program the processor’s memory to carry out the required functionality: software portion. These types are created to produce large numbers for a variety of applications

Here are some general characteristics from a general purpose processor:
 * Advantages:
 * easy to design and use (only programming the memory)
 * design time is thus low
 * design cost is thus low
 * reprogrammability (changing functionalities or improving a system becomes easy when you only need to change the program)
 * Disadvantages:
 * performance is not very good
 * size is high ( because they are built to be used in a variety of applications with different specifications and all these specifications must be possible on the processor)
 * they consume much power

Usually they are used to put in a product the first time it goes to the market, because of their cheap design cost and ease to use. Because of the use of code, a designer usually strives to minimize compiled code size, rather than maximize performance.

 * example:Microcontroller (MCU), Microprocessor

Basically a microprocessor performs all the tasks that must be accomplished by a microcontroller/embedded system. A general microprocessor consists of a bus unit which is a pathway to communicate with the (computer) memory, an instruction cache to keep track of instructions coming from the computer memory through the bus unit, a (pre)fetch unit copying instructions from the instruction cache for further processing, a decode unit getting instructions from the prefetch unit that will be converted to a binary code understood by the processor, a control unit that performs tasks or instructions which are comprised in the binary code coming from the decode unit, ‘data cache’ to save instructions or data, an ALU (arithmetic logic unit) that executes mathematic operations such as adding, multiplying…, and finally registers which are also some memory used by the ALU to store the results of performed operations. A microcontroller does not have a data bus or bus unit as described above for a general microprocessor. The reason is that there is no need to communicate to memory because memory is incorporated on the same chip as the microprocessor itself. A MCU is typically used as a systems controller, with many conditional operations and frequent changes in program flow. The MCU code is written in C or C++. There’s a wide variety of MCUs available: from 4-bit, 32 kHz models to 32-bit, 500 MHz devices, and beyond(The "-bit" designation refers to the width of a device's data bus, registers, execution units, etc.)

If you choose an embedded operating system (Windows, Linux, Dos...) a microprocessor is needed. But for real-time operations you better not use a microprocessor. The microcontroller is actually a low-end microprocessor, and is used in more simple tasks (traffic light to hold the light for a certain time...)

single purpose processor
This type of processor is designed to execute exactly one program. An embedded designer creates a single-purpose processor by designing a custom digital circuit Advantages and disadvantages are more or less the opposite of the general-purpose processor:
 * Advantages:
 * performance is very good
 * small size (exact to fit one solution)
 * they consume little power
 * Disadvantages:
 * not very easy to design and design time is thus high
 * design cost is thus higher
 * reprogramming is difficult
 * limited flexibility: not easy to make changes, accommodate features

In design we can make a difference between standard single-purpose processors and custom single-purpose processors (ASSP). The standard single-purpose processors (hardware peripherals) are explained in a different chapter Hardware Peripherals. They are used for in a wide variety of applications for the same task.

 * example: application-specific integrated circuit (ASIC),application-specific standard product (ASSP)

They are designed to fit the specific requirements of an end product. In the design process they will be optimised for both power and performance. An ASIC is introduced for a product usually after a product is stabilised on the market (with non-ASIC solution), because of the higher development time and cost. After the stabilisation the producer can look for extra margin by making the processor as good as possible for his application. A disadvantage is that when you make a mistake, you will need to make a whole new chip, but for a general-purpose processor you just change the code and recompile. You can use an ASIC in a stable market where technology and requirements aren't going to change rapidly.

application specific instruction-set processor (ASIP)
An ASIP is designed for a particular class of applications with common characteristics it’s an 'intermediate' solution between a general-purpose and a single-purpose processor and gives more flexibility than a single purpose processor and still better performance, power, size than a general purpose processor. Of course this leads to a longer design time (cost) and there's also a compiler problem, you will have to create your compiler usually yourself.

A DSP is optimized to efficiently perform repetitive and numerically intensive tasks such as matrix operations, convolution for filtering in real-time, because of the performance limitations of the MCUs. DSPs can run at very high clock rates, and they are often compared in terms of how many millions of MAC operations they can perform per second. This metric is known as "mega MACS," or MMACS.
 * example:Digital signal processor (DSP)

A DSP is optimized to do mathematical operations, but not for supervisory control. Thus, DSP-based systems are integrated with the slower MCUs, this can be done in 2 ways:
 * Discrete DSP + MCU (separate in the system)
 * Advantages:
 * design of DSP and MCU separate from each other
 * Disadvantages:
 * hard partitioning between control and DSP function, if there are too many instructions for the DSP, the MCU can’t take over
 * the DSP and MCU require different development tools
 * Convergent Processor (a convergent processor is optimized both for computation on real-time data flows, and for control-oriented tasks)
 * Advantages:
 * optimised for computation on real-time data flows as well as for control-oriented tasks
 * high clock rates
 * lower power dissipation
 * Disadvantages:
 * mixing a control application with signal processing on the same device, non-real-time tasks may interfere with time-critical tasks
 * the skills of developers must be higher

programmable logic device (PLD)
A processor exists of layers : the bottom layer are the transistors, if you connect the transistors you get logic gates and by connecting these you can make a circuit. In a PLD all layers already exist, the layers implement a programmable circuit, where programming has a lower-level meaning than a software program.

There are 2 types of Programmable Logic Device: Advantages of programmable logic devices over full-custom chips: There’s a large base of standard building-block libraries available for signal processing(fast development)  FPGAs like ASICS optimise hardware for a specific end product. They can also perform massively parallel computation (a MCU or DSP can’t). Because of their power consumption and cost, they shouldn’t be used in portable or cost-sensitive systems. The FPGA is able to talk to any external device thanks to it’s configurable nature. An ASIC can be created based on an FPGA implementation
 * simple PLD’s
 * Programmable Logic Array (PLA)
 * A PLA consists of a programmable array of AND gates and a programmable array of OR gates.
 * Programmable Array Logic (Pal)
 * A PAL consists of just one programmable array to reduce the number of expensive programmable components.
 * complex PLD’s
 * CPLD
 * A CPLD consists of ...[Fixme: definition]
 * field programmable gate array (FPGA)
 * A FPGA offers more general connectivity among blocks of logic, rather than just arrays of logic as with PLA’s and PAL’s, and are thus able to implement far more complex design.
 * low design cost (fast product development)
 * almost instant availability
 * Disadvantages
 * higher unit cost
 * bigger than ASICs
 * consume more power
 * example: FPGA

For more details, see Programmable Logic.

Trends for tomorrow

 * Multi core CPUs
 * Cell processor
 * GFX cards: With the increase in processing power available on these cards it becomes interesting to use them for more than just graphics processing alone.  They are especially good at parallel processing  and can be used as stream processors, they are then often referred to as GPGPUs. Currently only the NVIDIA CUDA and the ATI/AMD CTM systems are available.
 * Multi processor solutions: It is possible to use several different processors for controlling a system on different levels. For instance: microcontrollers can be used for low level local control, they can receive commands from a higher control level which might be implemented on an embedded cpu, which in turn can be reprogrammed with a general purpose cpu somewhere in a control room.

Manufacturers
The core business is automotive electronics systems. Melexis is also a manufacturer of fully protected microcontrollers with sensor compatible interfaces. The range of standard products involves among others microcontrollers and sensor IC’s. NXP delivers microcontrollers, integrated circuits and logic devices. Consultancy in embedded systems design. Coware is a company that focuses on ESL Electronic_system_level design of hard- and software of DSP systems. Easics is involved in the design of complete telecommunication products ASSP's Application specific standard product for telecommunication equipment manufacturers. The field of research and technology is broadband, embedded systems and wireless networks. The Atmel Corporation designs and manufactures advanced semiconductors, with focus on microcontrollers, nonvolatile memory, logic, radio frequency (RF) components and sensors. Microchip develops several microcontrollers under the name PIC for use in automotive applications, home appliances, thermal management, power management, etc. The company is also active in memory, radio frequency products and interfaces. MIPS offers a broad range of 32-bit and 64-bit processor cores for the worldwide embedded market. ARM develops  processors,  cache and SoC designs, application-specific standard products (ASSP's), related software and development tools. Renesas is a merger of the Hitachi and Mitsubishi semiconductor groups which develops the SuperH CPU cores, architecture and products (SuperH Texas Instruments offers a wide range of embedded processors, from the popular ultra-low power MSP430 to high speed DSPs. TI also specializes in analog and wireless solutions.
 * Melexis: http://www.melexis.be
 * NXP Semiconductors: http://www.nxp.com
 * Essentium: http://www.essentium.net
 * Coware: http://www.coware.com
 * Easics: http://www.easics.com/
 * Motorola : http://www.motorola.com
 * Atmel : http://www.atmel.com,
 * Microchip: http://www.microchip.com
 * MIPS_Technologies : http://www.mips.com
 * ARM Holdings: http://www.arm.com
 * Renesas: http://www.renesas.com
 * Texas Instruments : http://www.ti.com/

=Programmable Logic Controller (PLC)= The Programmable Logic Controller was born out of the need for a device which would eliminate the large cost involved in adjusting and replacing complicated relay based machine control systems. Programmable logic controllers are specialized industrial computers. The PLC is a real –time device: inputs from switches and sensors, evaluating these based on a program (logic) and changing the state of outputs to control a machine or process.

Advantages
A PLC is very simple in its use: programming, wiring, installation and changes are simple and quick. Another important feature of the PLC are its environmental possibilities: A PLC is designed for: A PLC exists not only out of a processor, but also the I/O arrangements: All PLCs contain six basic components:
 * Extended temperature ranges
 * Dirty or dusty conditions
 * Immunity to electrical noise
 * Resistance to vibration and impact
 * Processor or CPU
 * Rack or mounting
 * Input assembly (sensors can be analog or digital)
 * Output assembly
 * Power supply
 * Programming unit, device (PC)

PLC Program
The CPU executes a program. This logic can be written in Ladder Logic, Instruction List, Sequential Function Charts or any of the IEC languages. The program will be downloaded to the PLC.
 * Early PLC's: Ladder Logic
 * Recently IEC standard 61131-3 defines five languages
 * FBD (Function Block Diagram)
 * LD (Ladder Diagram)
 * ST (Structured Text)
 * IL (Instruction list)
 * SFC (Sequential Function Chart)

I/O capabilities
The main difference between a modern PLC and other processors are the I/O arrangements. These connect the PLC to sensors and actuators. Based on these arrangements PLC's can be divided into three groups: Modular, Rack and P2P. Modular PLC's have a limited number of connections built in for inputs and outputs (digital as well as analog). Expansions are available if the base model does not have enough I/O connections. Rack-style PLC's have processor modules with separate I/O modules which may occupy many racks. These often have thousands of discrete and analog inputs and outputs. Often a high speed serial I/O link is used so that racks can be remotely mounted from the processor, reducing the wiring costs for large plants. In larger I/O systems, PLC's may have P2P (peer to peer) communication between processors. This allows separate parts of a complex process to have individual control while allowing the subsystems to coordinate over the communication link.
 * Modular PLC's
 * Rack-style PLC's
 * P2P communication

Communication
The I/O modules can be located in the same rack of station. Communication then takes place within the rack or across the backplane. Backplane extension modules allow I/O modules to be located in racks or stations which are separated from the controller Modules can communicate with a controller over a network. Industrial networks are used to interconnect field level devices with controllers. ( FieldBus, ProfiBus and DeviceNet)
 * I/O-modules can communicate with a PLC's CPU by:
 * Backplane
 * Backplane extension
 * Device network
 * between PLCs:
 * serial communication
 * industrial communications network
 * industrial I/O network

disadvantages

 * it cannot handle complex situations
 * expensive, so it's not a good idea in mass-production
 * There's need for maintenance

-> A good reference for comparing a PLC with other types of processortechnology: ,

References to PLCs and programming ,,,,

Trends
To be able to handle more complex situations there is an evolution in the direction of the PC (PAC: programmable automation ) The boundary between PC and PLC is becoming less clear-cut. The languages also became more complex while evolving towards a more complex PLC.

-> An interesting link about its future and evolution towards PC: (in Dutch),

=Links and references=

by F. Vahid and T. D. Givargis by Rick Kuhlman by Joel Huebner by Kim Rowe by David Katz by Henk Capoen
 * Embedded Systems Design: A Unified Hardware/Software Introduction
 * http://www.embedded.com
 * Choosing the right industrial control and acquisition hardware: FPGA vs. PLC vs. custom hardware:
 * http://www.embedded.com/design/embeddedfpga/205204626?_requestid=475779                 [6]  [13]
 * http://www.industrialcontroldesignline.com/howto/204803436;jsessionid=HXS4CWE4VDV0YQSNDLOSKH0CJUNN2JVN     [5]
 * http://www.dspdesignline.com
 * Choices, choices, choices: choosing a correct processortype
 * http://www.smallformfactors.com/departments/fundamentals/2006/Winter/       [4]
 * How a microprocessor works:
 * http://www.intel.com/education/mpworks/ Intel education corner
 * http://computer.howstuffworks.com/microprocessor2.htm howstuffworks
 * Microprocessor Design
 * DSP system design: The basic laws: DSPs vs. FPGAs
 * http://www.dspdesignline.com/showArticle.jhtml;jsessionid=MQDAQJY5XYY5UQSNDLPCKH0CJUNN2JVN?articleID=206903789&queryText=dsp+system+design+basic+laws
 * http://www.dspdesignline.com/howto/206905097
 * Convergent processors solve development challenges
 * http://www.dspdesignline.com/howto/showArticle.jhtml?articleID=187203618    [2]
 * Introduction to the PLC:
 * http://www.plctutor.com/   [7]
 * http://www.plcs.net/contents.shtml Beginners PLC Primer    [8]
 * http://www.ccontrols.com/pdf/Extv4n2.pdf Interview with Dick Morley (pdf)   [9]
 * http://www.plcdev.com/plc_timeline Timeline of PLC History  [10]
 * http://mat.sourceforge.net Linux Open Source PLC project   [11]
 * Evolution and future of PLC(ppt)
 * http://www.regeltechnieken.org/PLC/Capoen-PLC.pdf future of PLC [12]


text:
Embedded Control Systems Design/Operating systems

Definition
An operating system is a computer program that manages the hard and software resources of a computer. It provides the interface between application programs and the system hardware. In general, an OS for embedded control systems has the following responsibilities: Task management and scheduling, interrupt servicing, inter process communication and memory management. These detailed topics will be discussed later on, as we first start with a more general approach of operating systems.

Necessity of an operating system
When choosing an operating system for an embedded control system, the first question that should be asked is: Is an operating system really necessary? For simple tasks or systems that only have to do one job, it might be easier and more efficient to create a program that runs directly on the microprocessor, perhaps using a super-loop architecture. An operating system will be needed when the embedded control system has to perform more complex tasks or be able to connect or interface with other devices for example. An operating system will allow for more flexibility. The following list gives an overview of the most common real time operating systems.

List of real-time operating systems

 * Linux based real-time operating systems :
 * RTAI
 * RTLinux
 * UCLinux
 * Other real-time operating systems :
 * eCos
 * Xenomai
 * VxWorks
 * WinCE
 * RTEMS (RTEMS for Embedded Software Developers)
 * QNX
 * FreeRTOS
 * MQX
 * BeRTOS

Things to consider when choosing an operating system
To facilitate the choice of the operating system, the following things can be considered:
 * Compatibility: Not every operating system works on any kind of microprocessor! So when choosing an operating system, one should already have an idea of the available hardware.
 * System Requirements and Footprint: The footprint of an embedded system is the total size of the system. For example, if the total size of an embedded control system is 600 kB, it can be said that the system's footprint is 600 kB. This is a small footprint, larger footprints would be in the order of some MB. A system's footprint has to be considered to make sure that the available hardware is able to support the system.
 * Software support: An other important factor in the choice of an operating system is the available supporting software. Are there many editors, compilers and libraries, or only very few? This is related to the next point on the list;
 * Amount of users: If one operating system is used by many people, there will be more available software for this system. It will also be easier to find documentation, solutions for specific problems or people that are using the same operating system.
 * Availability of device drivers
 * Possibility to dynamically add code: Sometimes it might be necessary to add programs to the already working system. Does the operating system allow this?
 * Certification: Some specific applications demand that the operating system is certified for use in that particular application. An example is the use of an operating system that will be used in space (satellites, rockets...)
 * Soft/Hard real-time: How important is it that timing constraints are met? In soft real-time, it is not a disaster (but not desirable) that a calculation is not completed within the specified time. Examples are audio and video playing. Nobody will notice a delay of a few microseconds. In hard real-time there is no exception: the system has to meet the specified timing constraints. Hard real time systems are for example surgical robots, space probes or precision mills.

When choosing an operating system, the following trends can also be considered:

 * Remote access: More and more it is a necessity that the system can be remotely accessed. Manufacturers that ship their machines all over the world cannot go to every location where there is one of their machines installed if they want to access the control system. Therefore remote accessing becomes increasingly important.
 * Safety Integrity Level: The safety integrity level is a relative measure of the reliability of a system. Systems that control dangerous processes should have a high SIL rating. To reach that SIL level, specific demands on soft and hardware are made. This can also affect the choice of an operating system.
 * Development of operating systems: There used to be hundreds of embedded operating systems available. When Microsoft introduced their WinCE system, a lot of systems disappeared, and programmers of different systems combined their efforts to create a common embedded operating system, thus further reducing the number of available systems.

Operation system basics
This section aims at a more detailed discussion of the basics of an operating system. As mentioned, the important tasks an embedded operating system has to do are: Task management and scheduling, interrupt servicing, inter process communication and memory management.

Task management and scheduling
A task (= process or thread) is an instance of a computer program that is being executed. While a program itself is just a passive collection of instructions, a process is something which actually executes those instructions. Several processes can be associated with the same program - each would execute independently. Modern computer systems allow multiple processes to be loaded into memory at the same time and, through time-sharing (or multitasking), give an appearance that they are being executed at the same time even if there is just one processor.

The difficult part in task management is to make sure that a specific task can exit without blocking other tasks. A task indeed should not be deleted blindly, because it shares a lot of its components with other tasks, so its memory space and locks should not be released when its causing tasks are still using them.

In general, multiple tasks will be active at the same time. The OS is responsible for sharing the available resources (CPU time, memory, etc.) over the tasks. The CPU is one of the important resources, and deciding how to share the CPU over the tasks is called scheduling.

The simplest approach to the scheduling problem is to assign static properties to all the tasks. That means that the priority is given to the task at the time it is created. Sometimes however, dynamic properties are assigned to a task: the schedule-algorithm has to calculate the task's priority on-line, based on a number of dynamically changing parameters (time till next deadline, amount of work to process, etc.). It's obvious that scheduling is pure overhead: all time spent on calculating which task to run next is lost for the really productive tasks.

Interrupts
An operating system also has to be able to service peripheral hardware, such as timers, motors, sensors, communication devices, disks, etc. All of those can request the attention of the OS asynchronously, i.e. at the time that they want to use the OS, the OS has to make sure it's ready to service the requests. Such a request for attention is called an interrupt.

There are two kinds of interrupts :
 * Hardware interrupts: the peripheral device can put a bit on a particular hardware channel that triggers the processor on which the OS runs, to signal that the device needs servicing. The result of this trigger is that the processor saves its current state, and jumps to an address in its memory space, that has been connected to the hardware interrupt at initialization time.
 * Software interrupts or Synchronous interrupt: many processors have built-in software instructions with which the effect of an hardware interrupt can be generated in software. The result of a software interrupt is also a triggering of the processor, so that it jumps to a pre-specified address. Examples of cases where software interrupts appear are perhaps a divide by zero, a memory segmentation fault, etc. So this kind of interrupt is not caused by an hardware event but by a specific machine language operation code. A synchronous interrupt is often called a trap.

Many systems have more than one hardware interrupt line, and the hardware manufacturer typically assembles all these interrupt lines in an interrupt vector. Hardware and software interrupts do share the same interrupt vector, but that vector then provides separate ranges for hardware and software interrupts.

An Interrupt Controller is a piece of hardware that shields the OS from the electronic details of the interrupt lines. Some controllers are able to queue interrupts, such that none of them gets lost.

We discuss interrupts in more detail in other chapters of this book, ../Real Time Operating systems and ../Design Patterns.

Inter process communication
Different tasks sometimes need to be synchronized, e.g. the sequence in which they are executed is important. It is also possible that tasks need to exchange data. An example is a peripheral device from which the data is processed by a dedicated task, which in turn passes the result on to another task. Synchronization and data exchanged are together called inter-process communication. An operating system should provide a wide range of inter-process communication primitives, so that tasks can easily be synchronized, or exchange data.
 * Synchronization
 * Semaphore A Semaphore is a protected variable (or abstract data type) and constitutes the classic method for restricting access to shared resources (e.g. storage) in a multiprogramming environment. It was invented by Edsger Dijkstra and first used in the THE operating system. The value of the semaphore is initialized to the number of equivalent shared resources it is implemented to control. In the special case where there is a single equivalent shared resource, the semaphore is called a binary semaphore. The general case semaphore is often called a counting semaphore. Semaphores are the classic solution to the dining philosophers problem, although they do not prevent all deadlocks.
 * Mutex The term mutex is short for "mutual exclusion", and is a type of mechanism used in a preemptive environment that can prevent unauthorized access to resources that are currently in use. Mutexes follow several rules: Mutexes are system wide objects, that are maintained by the kernel. Mutexes can only be owned by one process at a time. Mutexes can be acquired by asking the kernel to allocate that mutex to the current task. If a Mutex is already allocated, the request function will block until the mutex is available. In general, it is considered good programming practice to release mutexes as quickly as possible.
 * Condition variable To avoid entering a busy waiting state, processes must be able to signal each other about events of interest. Monitors provide this capability through condition variables. When a monitor function requires a particular condition to be true before it can proceed, it waits on an associated condition variable. By waiting, it gives up the lock and is removed from the set of runnable processes. Any process that subsequently causes the condition to be true may then use the condition variable to notify a process waiting for the condition. A process that has been notified regains the lock and can proceed.
 * Data exchange
 * Buffers A buffer is a region of memory used to temporarily hold output or input data, comparable to buffers in telecommunication. The data can be output to or input from devices outside the computer or processes within a computer. Buffers can be implemented in either hardware or software, but the vast majority of buffers are implemented in software. Buffers are used when there is a difference between the rate at which data is received and the rate at which it can be processed, or in the case that these rates are variable, for example in a printer spooler.
 * FIFO This term refers to the way data stored in a queue is processed. Each item in the queue is stored in a queue (simpliciter) data structure. The first data to be added to the queue (enqueue) will be the first data to be removed (dequeue), then processing proceeds sequentially in the same order.
 * Messages Message passing is a form of communication used in concurrent programming, parallel programming, object-oriented programming, and interprocess communication. Communication is made by the sending of messages to recipients.

Memory management
Terminology

When executing a task the system is in need of RAM memory. This RAM memory is mainly used for code, data management and IPC (Inter-process communication) with other tasks. The RAM makes it seem as if the task is the only one that is claiming the memory while running. Summarized it has three main tasks:
 * making the memory larger than it seems.
 * distributing the memory over a various of pages.
 * protecting the memory from access by other tasks.

When considering these general Operating System requirements, one has to keep in mind that they are not the concerns of real-time systems. The real-time requirements which have to be fulfilled are:
 * Fast and deterministic memory management: The fastest memory management is, of course, no memory at all. This means that the program can use all the physical RAM. This approach is only useful when programming small embedded control systems.
 * Page locking: Each task is getting a fixed number of pages in the RAM. Pages that hasn't been used recently are swapped out by a non deterministic process. When a task needs code or data from a swapped page, the system has to retrieve this page from the disk, which often requires another page in the RAM to be swapped out. This means the system has to lock pages of real time tasks. Otherwise there's a good chance that the necessary pages are being swapped out during the process. Page locking is thus a Quality of Service which means that each tasks gets the amount of memory it requires.
 * Allocation: It is always possible that a task is in need of more memory somewhere during the process. This extra memory is provided by a pool of free pages locked in the physical RAM. One has to be careful using this approach. It is never guaranteed that there are enough free pages available in the memory pool.
 * Memory mapping: Realtime and embedded systems have to access peripheral devices. These devices store their data in onboard registers. The registers then have to be mapped in the address space of the corresponding device driver task.
 * Memory sharing: shared memory allows different tasks to communicate with each other. The Operating system deallocates the shared memory and synchronizes access to that memory.
 * RAM disks: These disks can be used to emulate a hard disk. This means that memory is organized and entered as a file system. The benefits of this kind of memory management are:
 * 1) avoiding non-deterministic overhead of accessing hard disks.
 * 2) no extra cost.
 * 3) no extra space needed.
 * 4) no reduction of robustness of mechanical disk devices.

 * Flash disk: When a system is in need of data preservage while the power is switched off, the designer has to use flash disks. These disks can be burned repeatedly and they keep their memory when there is no power. The flash memory is loaded from within the system itself.
 * Stripped Libraries: RAM is scarce, so designers prefer to use stripped down versions of general utility libraries i.e. C library, GUI library etc...

Shared memory in Linux

There are various ways to allocate shared memory in Linux. When using RTLinux allocating is allowed, when using RTAI it's not.

 * Allocation at boot time: a block of shared memory can be reserved at boot time. This means that Linux cannot access it for general purposes. There is one problem though, boot-time allocation is not the best option for the average user: when only available for code linked in the image of the kernel, a device driver using this allocation can only be installed or replaced by rebuilding the kernel and rebooting the computer.
 * Allocation in kernel space: using this approach means that the memory does not have to be ready at boot time. Also there isn't a limit of the memory size. Unfortunately this isn't a real time process.
 * Allocation in module: In Linux there is an option called ‘Loadable Module Support’. This means that Linux can be divided in different modules that can be accessed and called. These modules are actually bits of code which places the kernel in the memory and takes it back out if wanted. This approach is preferably used at boot time.

Device drivers
The main goal of a device driver is to allow communication between the operating system and the peripheral devices. It also provides a link between the kernel software and the user software. It's important to achieve a sort of systematic way to do this. This makes the interface more recognizable for the user. The driver has the responsibility of hiding the details of the hardware from the operating system and, ultimately, from the user. This chapter will discuss a few of the available device drivers for embedded control systems.

Mechanism and policy

A device driver must provide mechanism, not policy. It has to supply the interfacing capabilities but nothing more (mechanism). A driver leaves the data alone, it may never alter a data stream (policy). It only makes it possible to use a device in a particular way.

Available device drivers

Writing a comedi device driver and the different steps in the writing process are explained here.
 * Unix device drivers: In Unix a device driver is actually part of the Unix kernel. This makes the drivers somewhat different from standalone programs. The kernel exists out of base code plus driver code that helps the system communicating with the hardware. The following steps have to be checked when writing a device driver in Unix:
 * Namespace: before writing any code it is important to name your device.
 * Memory allocation: the kmalloc function is used. This means that memory is provided in pieces whose size is a power of two. There is a limit to this namely 131056 bytes. Also, kmalloc requires a second argument: priority. Kfree will then give you the opportunity to allocate memory.
 * Character vs. block devices: these are the two main types of devices under Unix. Character devices use no buffer and block devices are accessed via a cache.
 * Interrupts vs. Polling: There is a difference between interrupt device drivers and polling device drivers. In Unix the kernel is not a separate task. Each part or process of the system has its own copy of the kernel. When the system gives a call to execute some task to a process, this is said to be "in kernel mode". The process hasn't transferred control to another process. In kernel mode it is obvious where to place the data because the process is running in its own mode. When interrupts occur however, they will alter this dataplacement and may cause macro's (which allow the system to access user-space memory) to write over random memory space of cause the kernel to crash. The driver has to schedule a interrupt and while doing that it must provide temporary space to put information in. In a block device driver this temporary space is arranged by the buffer. When using a character device driver, the device driver itself is responsible for the allocation.
 * Complex device drivers: a normal device driver does nothing more than writing and reading a datastream to or from a peripheral device. When a device needs interrupts to communicate with the users software these drivers tend to be a little bit more complex. These kind of drivers are in need of a ISR and possibly also a DSR. There is also another reason why a device driver could become complex: some devices allow shared memory or even Direct Memory Access. This means that no processor is used to exchange data. An operating system must support DMA. When designing a complex device driver it is best to standardize the structure and the API for the device:
 * API: when a device offers similar mechanisms as other devices the designer has use the same software interface.
 * Structure: The device driver must be able to cope with more layers of functionality of the interfaces.
 * Comedi:Data acquisition cards are used for measurements and control purposes. Comedi will provide a interface for them.It's a balance between modularity and complexity. Here are some issues that designers have to keep in mind when dealing with Comedi:
 * It works on a standard Linux kernel as well on RTAI and RTLinux.
 * It consists of two packages: Kcomedilib and Comedilib.
 * The cards have the following features:
 * analog input/output channels.
 * digital input/output channels.
 * The kernel space structure uses a specific hierarchy:
 * channel: represents the properties of one single data channel.
 * sub-device: functionally identical channels.
 * device: set of subdevices. Thus the interface card itself.
 * The basis functionalities are:
 * instruction: synchronously perform one single data acquisition.
 * scan: repeated instructions of a number of different cards.
 * command: start or stop the data acquisition.
 * It allows to query the capabilities of the installed Comedi devices.
 * It offers event-driven functionality.
 * It provides locking primitives when multiple devices are accessed at the same time.

 * Real-time serial line drivers: these kind of device drivers are integrated into RTAI. They provide:
 * very configurable address initialization,
 * interrupt handling,
 * buffering, callbacks, non-intrusive buffer inspection,...
 * Real-time parallel port drivers: these kind of drivers are integrated in Comedi. They allow the real-time interrupt handler to be connected to the interrupt on a parallel port.
 * Real-time networking drivers: integrated in the RTAI, it provides a common programming interface between RTOS and the device drivers of ethernet networks.

POSIX
When developing an operating systems, there is a wide range of advantages if the design is according to certain standards. Software is developed in teams, and standards make the design far easier, faster and more transparent. Standards increase the portability of existing applications to new hardware. They also facilitate the cooperation of different pieces of software.

POSIX or "Portable Operating System Interface" is the collective name of a family of related standards specified by the IEEE to define the application programming interface (API) for software compatible with variants of the Unix operating system. POSIX specifies the user and software interfaces to the OS in some 15 different documents. For real-time systems, POSIX has the following standards:

POSIX defines profiles for real-time systems, based on the presence of a file system and the number of processes.

Things yet to mention

 * Kernel vs User space ?
 * Deadlocks ?