|
Organizer and Guest
Editor: Guest Editorial: I. INTRODUCTION
The advances in
design of embedded systems, tools availability, and falling
fabrication costs of semiconductor devices and systems
(systems-on-chip) allowed for infusion of intelligence in to field
devices such as sensors and actuators. The controllers used with these
devices provide typically on-chip signal conversion, data and signal
processing, and communication functions. The increased functionality,
processing and communication capabilities of controllers have been
largely instrumental in the emergence of a wide-spread trend for
networking of field devices around specialized networks, frequently
referred to as field area networks. Although for the origins of field area networks, one can look back as far as the end of 1960s in the nuclear instrumentation domain, CAMAC network [2], and beginning of 1970s in avionics and aerospace applications, MIL-STD-1553 bus [3], it was the industrial automation area which brought the main thrust of developments. The need for integration of heterogeneous systems, difficult at the time due to the lack of standards, resulted in two major initiatives which have had a lasting impact on the integration concepts, and architecture of the protocol stack of field area networks. These initiatives were TOP (Technical and Office Protocol) [4] and MAP (Manufacturing Automation Protocol) [5] projects. The two projects exposed some pitfalls of the full seven-layer stack implementations (ISO/OSI model [6]) in the context of applications in industrial automation. As a result, typically, only the layers 1 (physical layer), 2 (data link layer, including implicitly the medium access control layer), and 7 (application layer, which covers also user layer) are used in the field area networks [7]; also prescribed in the international fieldbus standard, IEC 61158 [8]. In IEC 61158, functions of layers 3 and 4 are recommended to be placed either in layer 2 or layer 7; functions of layers 5 and 6 are covered in layer 7. The evolution of fieldbus technology which begun well over two decades ago has resulted in a multitude of solutions reflecting the competing commercial interests of their developers and standardization bodies, both national and international: IEC [9], ISO [10], ISA[11], CENELEC [12] and CEN[13]. This is also reflected in IEC 61158 (adopted in 2000), which accommodates all national standards and user organization championed fieldbus systems. Subsequently, implementation guidelines were compiled in to Communication Profiles, IEC 61784-1, [14]. Those Communication Profiles identify seven main systems (or Communication Profile Families) known by brand names as Foundation Fieldbus (H1, HSE, H2) used in process and factory automation; ControlNet and EtherNet/IP both used in factoryl automation; PROFIBUS (DP, PA) used in factory and process automation respectively; PROFInet used in factory automation; P-Net (RS 485, RS 232) used in factory automation and shipbuilding; WorldFIP used in factory automation; INTERBUS, INTERBUS TCP/IP, and INTERBUS Subset used in factory automation; Swiftnet transport, Swiftnet full stack used by aircraft manufacturers. The listed application areas are the dominant ones. Ethernet, the backbone technology of the office networks, is increasingly being adopted for communication in factories and plants at the fieldbus level. The random and native CSMA/CD arbitration mechanism is being replaced by other solutions allowing for deterministic behavior required in real-time communication to support soft and hard real-time deadlines, time synchronization of activities required to control drives, for instance, and for exchange of small data records characteristic of monitoring and control actions. A variety of solutions have been proposed to achieve this goal. Some can coexist with regular Ethernet nodes; some reuse the same hardware but are incompatible; some are compatible but cannot offer guarantees in presence of nodes that do not implement the same modifications – as classified in paper “Ethernet Based Real-Time and Industrial Communications”, by Jean-Dominique Decotignie, included in this issue. The emerging Real-Time Ethernet (RTE), Ethernet augmented with real-time extensions, under standardization by IEC/SC65C committee, is a fieldbus technology which incorporates Ethernet for the lower two layers in the OSI model. There are already a number of implementations, which use one of the three different approaches to meet real-time requirements. The use of standard components such as protocol stacks, Ethernet controllers, bridges, etc, allows for mitigating the ownership and maintenance cost. The direct support for the Internet technologies allows for vertical integration of various levels of industrial enterprise hierarchy to include seamless integration between automation and business logistic levels to exchange jobs and production (process) data; transparent data interfaces for all stages of the plant life cycle; the Internet- and web-enabled remote diagnostics and maintenance, as well as electronic orders and transactions. The use of wireless links with field devices, such as sensors and actuators, allows for flexible installation and maintenance, mobile operation required in case of mobile robots, and alleviates problems with cabling. A wireless communication systems to operate effectively in the industrial/factory floor environment has to guarantee high reliability, low and predictable delay of data transfer (typically, less than 10 ms for real time applications), support for high number of sensor/actuators, and low power consumption, to mention some. In the industrial environments, the wireless channel characteristic degradation artifacts can be compounded by the presence of electric motors or a variety of equipment causing the electric discharge, which contribute to even greater levels of bit error and packet losses. Improving channel quality and designing robust and loss-tolerant applications, both subject of extensive research and development, seem to have a potential to alleviate the problems to some extent. Some of these solutions are discussed in the issue in the paper “Wireless Technology in Industrial Networks” by Andreas Willig, at. al. In addition to peer-to-peer interaction, the sensor/actuator stations communicate with the base station(s), which may have its transceiver attached to the cable of a fieldbus, thus, resulting in a hybrid wireless- wireline fieldbus system. To leverage low cost, small size, and low power consumptions, Bluetooth 2.4 GHz radio transceivers may be used as the sensor/actuators communication hardware. To meet the requirements for high reliability, low and predictable delay of data transfer, and support for high number of sensor/actuators, custom optimized communication protocols may be required for the operation of the base station as the commercially available solutions such as IEEE 802.15.1/ Bluetooth [15] [16], IEEE 802.15.4/ZigBee [17], and IEEE 802.11 [18], [19], [20] variants may not fulfill all the requirements. The growing trend for horizontal and vertical integration of industrial automated enterprises, largely achieved through internetworking of the plant communication infrastructure, coupled with a growing demand for remote access to process data at the factory floor level exposes automation systems to potential electronic security attacks, which may compromise the integrity of these systems and endanger plant safety. Safety, or the absence of catastrophic consequences for humans and environment, is, most likely, the most important operational requirement for automation and process control systems. Another important requirement is the system/plant availability; the automation system and plant have to be safe operational over extended periods of time, even if they continue operation in a degraded mode in the presence of a fault. With this requirement, security software updates in the running field devices may be difficult, or too risky. The limited computing, memory, and communication bandwidth resources of controllers embedded in the field devices pose considerable challenge for the implementation of effective security policies which, in general, are resource demanding. This limits the applicability of the mainstream cryptographic protocols, even vendor tailored versions. The operating systems running on small footprint controllers tend to implement essential services only, and do not provide authentication or access control to protect mission and safety critical field devices. As pointed out in the paper on security in this issue, “Security for Industrial Communication Systems”, by Dacfey Dzung at. al., “security is a process, not a product”. This motto embeds practical wisdom that solutions depend on specific application areas, systems, and devices to be protected. Another fast growing application area for the field area networks is building automation [21]. Building automation systems aim at the control of the internal environment, as well as the immediate external environment of a building, or building complex. At present, the focus of research and technology development is on commercial type of buildings such as office building, exhibition centre, shopping complex, etc. However, the interest in (family type) home automation is on the rise. Some of the main services to be offered by the building automation systems typically include: climate control to include heating, ventilation, air conditioning; visual comfort to cover artificial lighting, control of day light; safety services such as fire alarm, and emergency sound system; security protection; control of utilities such as power, gas, water supply, etc.; internal transportation systems to mention lifts, escalators, etc. The communication architecture supporting automation systems embedded in the buildings has typically three levels: field level, control level, and management level. The field level involves operation of elements such as switches, motors, lighting cells, dry cells, etc. The automation level is typically used to evaluate new control strategies for the lower level in response to the changes in the environment; reduction in the day light intensity, external temperature change, etc. LonWorks [22], BACnet [23], and EIB/KNX [24] [25] [26] [27], open system networks for building automation, are suitable for use at more then one level of the communication architecture. In terms of the quality of the service requirements imposed on the field area networks, building automation systems differ considerably from their counterparts in industrial automation. There is seldom a need for hard real-time communication; the timing requirements are much more relaxed. Traffic volume in normal operation is low. Typical traffic is event driven, and mostly uses peer-to-per communication paradigm at the field level; toggling a switch activates lighting cell(s), for instance. Fault tolerance and network management are important aspects. In building automation networks, unlike in industrial automation, the routing functionality and end-to-end control is typically needed arising from the hierarchical network structure. LonTalk [ 22 ], for instance, implements all seven layers of the OSI model. Trends for networking also appear in the automotive electronic systems where the Electronic Control Units (ECUs) are networked by means of one of automotive communication protocols for the purpose of controlling one of the vehicle functions; for instance electronic engine control, anti-locking break system, active suspension, telematics, to mention a few. There are a number of reasons for the interest of the automotive industry in adopting field area networks and mechatronic solutions, known by their generic name as X-by-Wire, aiming to replace mechanical or hydraulic systems by electrical/electronic systems. The main factors seem to be economic in nature, improved reliability of components, and increased functionality to be achieved with a combination of embedded hardware and software. Steer-by-Wire, Brake-by-Wire, or Throttle-by-Wire systems are representative examples of X-by-Wire systems. The dependability of X-by-Wire systems is one of the main requirements, as well as constraints on the adoption of this kind of systems. But, it seems that certain safety critical systems such as Steer-by-Wire and Brake-by-Wire will be complemented with traditional mechanical/hydraulic backups, for safety reasons. Another equally important requirement for the X-by-Wire systems is to observe hard real-time constraints imposed by the system dynamics; the end-to-end response times must be bounded for safety critical systems. A violation of this requirement may lead to performance degradation of the control system, and other consequences as a result. Not all automotive electronic systems are safety critical, or require hard real-time response. For instance, system(s) to control seats, door locks, internal lights, etc, are not. Different performance, safety, and QoS requirements dictated by various in-car application domains necessitate adoption of different solutions, which, in turn, gave rise to a significant number of communication protocols for automotive applications - some of those protocols are overviewed in this issue in paper “Trends in Automotive Communication Systems” by Nicolas Navet, at.al. For instance, time-triggered protocols, based on TDMA (Time Division Multiple Access) medium access control technology, are particularly well suited for the safety critical solutions, as they provide deterministic access to the medium. In this category, TTP/C [28] protocol have been experimented with and considered for deployment for quite some time. However, to date, there have been no actual implementations of that protocol involving safety critical systems in commercial automobiles, or trucks. In 1995, a “proof of concept”, organized jointly by Vienna University of Technology and DaimlerChrysler, demonstrated a car equipped with a “Brake-by-Wire” system based on time-triggered protocol. The FlexRay [29] protocol (FlexRay supports a combination of both time-triggered and event-triggered transmissions) appears to be the frontrunner for potential safety-critical applications in future. FlexRay is a joint effort of a consortium involving some of the leading car makers and technology providers to mention BMW, Bosch, Daimler-Chrysler, General Motors, Motorola, Philips and Volkswagen, as well as Hyundai Kia Motors as a premium associate member with voting rights. Both TTP/C and FlexRay provide additional dependability mechanisms and services which make them particularly suited for safety-critical systems, to mention replicated channels and redundant transmission mechanisms, bus guardians, fault-tolerant clock synchronization, membership service, etc. The cooperative development process of networked automotive applications brings with itself heterogeneity of software and hardware components. Even with the inevitable standardization of those components, interfaces, and even complete system architectures, the support for reuse of hardware and software components is limited. Thus potentially making the design of networked automotive applications labor-intensive, error-prone, and expensive. This situation necessitates the development of component-based design integration methodologies, and automotive-specific middleware. One of the main bottlenecks in the development of safety-critical systems is software development process. The automotive industry clearly needs a software development process model and supporting tools suitable for the development of safety-critical software. At present, there are two potential candidates: MISRA (Motor Industry Software Reliability Association) [30] published recommended practices for safe automotive software. The recommended practices, although automotive specific, do not support X-by-Wire. IEC 61508 [31] is an international standard for electrical, electronic and programmable electronic safety related systems. IEC 61508 is not automotive specific, but broadly accepted in other industries. The objective of this issue is to give a broad overview of the area of industrial communication networks, with a focus on industrial automation in manufacturing and process industries. To give a better appreciation of other application areas, the use of specialized field area networks in building automation control and in automotive applications is presented as well. The material presents relevant technologies, together with their evolution and standardization activities, and current standards. It also describes on-going research and industry implementations, recommended practices adopted by industry, and gives a perspective on current research and development activities driven largely by industrial groups and consortia.
II. PAPER
DESCRIPTIONS A comprehensive overview of the fieldbus concept and its evolution, the standardization process, and technical aspects are presented in the paper “Fieldbus Technology in Industrial Automation”, authored by Jean-Pierre Thomesse who was directly involved in the development of the WorldFIP fieldbus and its standardization. This paper gives a captivating account of the origins of the fieldbus technology by outlining evolution phases driven by a combination of requirements imposed by specific industries and application domains requirements, and standardization activities. This part of the paper is an essential reading for anyone wishing to understand the reason for the large number of fieldbuses in existence today. It also presents a round up of the current standardization activities, and an overview of some of the main standards. A technical analysis of fieldbuses is presented in the second part of the paper. It discusses, layer-by-layer, a typical of fieldbuses three-layer protocol stack architecture in the context of the seven-layer OSI model. It methodically shows some possible distributions of the services offered by the layers of the OSI model among the three layers of the fieldbus stack. The remaining part of the section provides a comprehensive overview of the concepts essential to understand the fieldbus technology. This paper is one of the most exhaustive treatments of fieldbuses, written with clarity and erudition of the technology insider. An excellent introduction to Ethernet and ways to extend its operation to incorporate real-time requirements is presented in paper “Ethernet Based Real-Time and Industrial Communications”, by Jean-Dominique Decotignie. The paper gives an overview of selected characteristics of an industrial communication system. This discussion includes application model, network model, data model, error model, and soft versus hard real-time constraints. Subsequently, the paper introduces the conventional Ethernet together with its pros and cons, followed by a brief account of the technology evolution. The different approaches to improve the real-time behavior, surveyed and evaluated in the paper, are based on the reuse of existing Ethernet hardware. Specifically, the approaches presented deal with modifications that either alter or keep compatibility with existing Ethernet hardware. The paper also discusses and analysis some of major requirements of industrial communication systems, namely action synchronization and temporal consistency. It demonstrates that the two cannot be achieved without adding a new layer of protocols dealing with time synchronization. The focus of the paper “Real-Time Ethernet – Industry Perspective”, by Max Felser, is on Real-Time Ethernet; its standardization and proposals for and actual implementations. The paper explains in detail the structure of the IEC/SC65C standardization committee, and gives a round up of activities to date. In the context of the standardization process, the paper overviews requirements for Real-Time Ethernet. Second part of the paper gives a comprehensive overview of the proposals for standardization together with their key technical features. These proposals are, in general, based on the three different approaches to meet real-time requirements. First approach is based on retaining the TCP/UDP/IP protocols suite unchanged (subject to non deterministic delays). In this case, all real-time modifications are enforced in the top layer. In the second approach, the TCP/UDP/IP protocols suite is bypassed, the Ethernet functionality is accessed directly – in this case, RTE protocols use their own protocol stack in addition to the standard IP protocol stack. Finally, in the third approach, the Ethernet mechanism and infrastructure are modified. Each of the proposed solutions is described, as far as the details are available, in terms of the protocol implementation, topology and performance, and application protocol model. A comprehensive overview of wireless communications in the industrial environment and relevant technologies, is presented in paper “Wireless Technology in Industrial Networks”, by Andreas Willig, at. al. To better appreciate the requirements imposed on wireless communications in the industrial environment, the paper gives an overview of the adverse effects of the transmission errors and certain wireless channel properties on the packet transmission timing and reliability. Subsequently, the paper presents a comprehensive overview of the commercial-of-the-shelf wireless technologies to include IEEE 802.15.1/Bluetooth, IEEE 802.15.4/ZigBee, and IEEE 802.11 variants. The suitability of these technologies for industrial deployment is evaluated to include aspects such as application scenarios and environments, coexistence of wireless technologies, and implementation of wireless fieldbus services. The last segment of the paper deals with the integration issues and techniques involved in the hybrid wireless-wireline fieldbus systems. This material is illustrated by using a PROFIBUS based case study. The paper “Security for Industrial Communication Systems”, by Dacfey Dzung at. al., gives an overview of the IT security technologies, best practices for industrial communication system security, and introduces some standardization activities in the area. It discusses security objectives, types of attacks, and the available countermeasures for general IT systems. The emphasis is on the TCP/IP protocol suite and the available cryptography-based secure communication protocols. Subsequently, the paper discusses security-relevant characteristics of industrial communication systems, and main types of industrial and utility communication network topologies and protocols, which have an influence on the implementation of security architectures. This is followed by a comprehensive discussion of security issues and solutions for industrial automation protocols on LAN / WAN level, security on the fieldbus and device level, and security in the networked embedded systems. The presented concepts and elements of IT security for industrial and utility communication systems are illustrated by two case studies describing security issues and recommendations for network configuration in electric-energy substation automation, and plant automation. A general overview of the building automation area and the supporting communication infrastructure is presented in paper “Communication Systems for Building Automation and Control”, by Wolfgang Kastner at. al. The paper provides an extensive description of building service domains, the concepts of building automation and control, and introduces building automation hierarchy together with the communication infrastructure. The discussion of control networks for building automation covers aspects such as selected quality of service requirements and related mechanisms, horizontal and vertical communication, network architecture, and internetworking. As with industrial fieldbus systems, there are a number of bodies involved in the standardization of technologies for building automation. The paper overviews some of the standardization activities, standards, as well as networking and integration technologies. Open systems BACnet, LonWorks and EIB/KNX are introduced at the end of the paper. The focus is on standardization and certification, physical characteristics, communication patterns, application data models, services, and standard hardware components as well as commissioning tools. The paper “Trends in Automotive Communication Systems”, by Nicolas Navet, at.al., provides a broad overview of the field of automotive communication systems. Based on functional, performance, and safety requirements, the paper identifies a number of application domains for automotive networks: powertrain domain, chassis domain, body domain, telematics domain, and multimedia and Human Machine Interface domains. Subsequently, the SAE (Society for Automotive Engineers) classification of automotive communication protocols is introduced. The overview of selected automotive networks and protocols is centered around priority busses, which incorporate priority mechanisms, to include CAN (Controller Area Network), VAN (Vehicle Area Network), and J1850; time triggered networks: TTP/C (Time Triggered Protocol), FlexRay, and TTCAN (Time Triggered CAN); low-cost automotive networks such as LIN (Local Interconnect Network) and TTP/A; and multimedia oriented solutions: MOST and IDB-1394. The last major part of the paper has a focus on the software middleware layer for automotive applications. It presents a rationale for this layer and discusses specific requirements. The overview of the state-of-the-art of the automotive middleware includes OSEK/VDX communication environment (OSEK/VDX COM), OSEK/VDX fault-tolerant communication layer (OSEK/VDX FTCom), and Volcano development process and supporting tools. ACKNOWLEDGEMENT The guest editor wishes to express his gratitude to the reviewers who volunteered a great deal of their time to provide feedback to the authors. He would also like to thank authors for their important contributions to this special issue.
Richard Zurawski REFERENCES
[1] The Industrial Communication Technology Handbook, ed. R. Zurawski, CRC Press, Florida, 2005.
[3] Gifford,-C.-A., (1974). “A military standard for multiplex data bus”. Proceedings of the IEEE-1974, National Aerospace and Electronics Conference. 13-15 May 1974 Dayton, OH, USA, pp. 85-8. [4] S. R. Dillon, “Manufacturing automation protocol and technical and office protocols - success through the OSI model”, in Proceedings of Compcon Spring'87; IEEE Computer Society, February 23-27, 1987, San Francisco, CA, pp. 80-81. [5] H. A. Schutz, "The Role of MAP in Factory Integration". IEEE Transactions on Industrial Electronics, vol. 35, no. 1, 1988, pp. 6-12. [6] Zimmermann H., “OSI Reference Model: The ISO model of architecture for open system interconnection”, IEEE Transactions on Communications, 28(4): 425-432, 1980. [7] P. Pleinevaux, J.-D. Decotignie, “Time Critical Communication Networks: Field Buses”, IEEE Network, Vol. 2, pp. 55–63, 1988. [8] International Electrotechnical Commission, IEC 61158-1, Digital data communications for measurement and control - Fieldbus for use in industrial control systems, Part 1: Introduction, 2003 [9] International Electrotechnical Commission [IEC]. [Online] www.iec.ch [10] International Organization for Standardization [ISO]. [Online] www.iso.org [11] Instrumentation Society of America [ISA]. [Online] www.isa.org [12] Comité Européen de Normalisation Electrotechnique [CENELEC] [Online] www.cenelec.org [13]. European Committee for Standardization [CEN]. [Online] www.cenorm.be [14] International Electrotechnical Commission, IEC 61784-1, Digital data communications for measurement and control - Part 1: Profile sets for continuous and discrete manufacturing relative to fieldbus use in industrial control systems, 2003 [15] Bluetooth Consortium, Specification of the Bluetooth System, 1999. [Online] www.bluetooth.org. [16] Bluetooth Special Interest Group, Specification of the Bluetooth System, Version 1.1, December 1999; www.bluetooth.com. [17] LAN/MAN Standards Committee of the IEEE Computer Society, IEEE Standard for Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements – Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (LR-WPANs), Oct. 2003. [18] LAN/MAN Standards Committee of the IEEE Computer Society, IEEE Standard for Information Technology – Telecommunications and information exchange between systems - Local and Metropolitan networks - Specific requirements – Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Higher speed Physical Layer (PHY) extension in the 2.4 Ghz band, 1999. [19] LAN/MAN Standards Committee of the IEEE Computer Society, Information technology – Telecommunications and Information Exchange between Systems – Local and Metropolitan Area Networks – Specific Requirements – Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 1999. [20] Institute of Electrical and Electronic Engineering “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Amendment 4: Further Higher Data Rate Extension in the 2.4 GHz Band,” June 2003, aNSI/IEEE Std 802.11. [21] Deborah Snoonian, “Smart buildings”, IEEE Spectrum, 40(8):18-23, 2003. [22] D. Loy, D. Dietrich, and H. Schweinzer, Open Control Networks, Kluwer, 2004. [23] Steven T. Bushby. BACnet: “A standard communication infrastructure for intelligent buildings”, Automation in Construction, 6(5-6):529-540, 1997. [24] ENV 13154-2 (1998): Data communication for HVAC applications - Field net -Part 2: Protocols. [25] EIA/CEA 776.5-1999, CEBus-EIB Router Communications Protocol - The EIB Communications Protocol [26] EN 50090-X (1994-2004), Home and Building Electronic Systems (HBES) [27] Konnex Association, Diegem, Belgium. KNX Specifications, V. 1.1, 2004. [28] TTTech Computertechnik GmbH. Time-Triggered Protocol TTP/C, High-Level Specification Document, Protocol Version 1.1, November 2003. [ Online] www.tttech.com. [29] FlexRay Consortium, FlexRay Communication System, Protocol Specification, Version 2.0, June 2004. [ Online] www.flexray.com. [30] [Online] www.misra.org.uk [31] International Electrotechnical Commission, IEC 61508:2000, Parts 1-7, Functional Safety of Electrical/ Electronic/ Programmable Electronic Safety-Related Systems, 2000. Guest Editor: short biography Contents of the Issue: |
Proceedings of the IEEE