Image Processing Reference
In-Depth Information
heirstapplicationoftheOSImodeltothedomainofautomationwasthedeinitionofthe
manufacturing automation protocol (MAP) in the wake of the CIM idea []. MAP was intended
to be a framework for the comprehensive control of industrial processes covering all automation
levels, and the result of the definition was a powerful and flexible protocol []. Its complexity, how-
ever, made implementations extremely costly and hardly justifiable for general-purpose use. As a
consequence, a tightened version called MiniMAP and using a reduced model based on the OSI
layers , , and was proposed to better address the problems of the lower automation layers [].
Unfortunately, it did not have the anticipated success either. What did have success was the manufac-
turing message specification (MMS). It defined the cooperation of various automation components
by means of abstract objects and services and was later used as a starting point for many other field-
bus definitions []. he missing acceptance of MiniMAP as well as the inapplicability of the original
MAP/MMS standard to time-critical systems [] was finally the reason for the IEC to launch the
development of a fieldbus based on the MiniMAP model, but tailored to the needs of the field level.
According to the original objectives, the higher levels of the automation hierarchy should be covered
by MAP or PROWAY [].
Independent of this development in computer science, the progress in microelectronics brought
forward many different integrated controllers, and new interfaces were needed to interconnect the
ICs in an efficient and cheap way. he driving force was the reduction of both the interconnect wires
on the printed circuit boards and the number of package pins on the ICs. Consequently, electrical
engineers—without the knowledge of the ISO/OSI model or similar architectures—defined simple
busses like the I
C. Being interfaces rather than full-fledged bus systems, they have very simple
protocols, but they were and still are widely used in various electronic devices.
Long before the “invention” of board-level busses, the demand for a reduction of cabling weight
in avionics and space technology had led to the development of the MIL STD bus, which can be
regarded as the first “real” fieldbus. Introduced in , it showed many characteristic properties of
modern ieldbus systems: serial transmission of control and data information over the same line, mas-
ter/slave structure, the possibility to cover longer distances, integrated controllers, and it is still used
today.Lateron,similarthoughts(reductionofcablingweightandcosts)resultedinthedevelopment
of several bus systems in the automotive industry, but also in the automation area. A characteristic
property of these fieldbusses is that they were defined in the spirit of classical interfaces, with a focus
on the lower two protocol layers, and no or nearly no application layer definitions. With time, these
definitions were added to make the system applicable to other areas as well. CAN is a good exam-
ple of this evolution: For the originally targeted automotive market, the definition of the lowest two
OSI layers was sufficient. Even today, automotive applications of CAN typically use only these low-
level communication features because they are easy to use and the in-vehicle networks are usually
closed. For applications in industrial automation, however, where extensibility and interoperability
is an important issue, higher-level functions are important. So, when CAN was found to be interest-
ing also for other application domains, a special application layer was added. he lack of such a layer
in the original definition is the reason why there are many different fieldbus systems (like CANopen,
smart distributed system [SDS], DeviceNet) using CAN as a low-level interface.
From today's point of view, it can be stated that all fieldbusses that still have some relevance were
developed using the “top-down” or “computer science-driven” approach, i.e., a proper protocol design
with abstract high-level programming interfaces to facilitate usage and integration in complex sys-
tems. he fieldbusses that followed the “bottom-up” or “electrical engineering-driven” approach, i.e.,
that were understood as low-level computer interface, did not survive due to their inflexibility and
incompatibility with modern software engineering, unless some application layer functions were
included in the course of the evolution.
From the early s on, when automation made a great leap forward with PLCs and more
intelligent sensors and actuators, something like a gold rush set in. he increasing number of devices
used in many application areas called for a reduced cabling, and microelectronics had grown mature
