Internet of Things at Work: Enabling Plug-and-Work in
Automation Networks
Amine M. Houyou, Hans-Peter Huth
Communication Systems & Control Networks
Corporate Research and Technologies
Siemens AG, Germany
{amine.houyou, hans-peter.huth}@siemens.com
Abstract
The Internet of Things (IoT) technologies have recently gained a lot of interest from numerous
industries, where devices, machines, sensors, or simply things are talking to each other over
standard Internet technologies. The need for standardized technologies and architectures to
make networking these new applications is a challenge that is addressed by the Europe an
Commission in its ICT research program. The IoT@Work European funded research project
coordinated by Siemens is focusing on the industry automation and its networking and
communication needs. The project will use FIAT research centre (CRF) facilities to
demonstrate its technologies developed in cooperation with European Microsoft Innovation
Center (EMIC), TXT e-Solutions, Institute Industrial IT (inIT) and City University London.
Process and industry automation have strong demands for reliable communication and
security guarantees, which an IoT architecture has to incorporate from the start. Today,
deployment and commissioning of complex production processes or Internet-enabled
applications interacting with production systems still require a time consuming and errorprone manual network configuration process. This is due to the need to maintain a high level
of determinism, safety, and security of the production process itself and avoiding both safetycritical failures and costly production interruptions. Furthermore, the traditional concept of a
‘system’s boundary’ does not scale in scenarios where repurposed production systems have
to fulfil new goals and adapt aspects like connectivity, dependability, and security. IoT@Work
will deliver tools and runtime mechanisms based on IoT technologies to significantly simplify
commissioning, operating, and maintaining complex production processes. The contribution
of this project will be focused on using self-configuration mechanisms, enabling what we call
secure Plug&Work IoT. This paper will introduce the problem domain and its challenges and
present the approach followed in the project. The focus of this report is on the findings of the
first project phase, namely an extensive study of real-world scenarios to identify the
requirements for future agile automation.
1
Introduction
The Internet of Things (IoT) technologies have recently gained a lot of interest from numerous
industries, where devices, machines, sensors, or simply things are talking to each other over
standard Internet technologies. The need for standardized technologies and architectures to
make networking these new applications is a challenge that has been addressed by the
European Commission in its ICT research program.
Some of the existing projects, in the field, focus on the problem of making "things" Internet
enabled, that is adding intelligence and connectivity, e.g. by means of RFIDs to every day
objects/things. Other projects focus on how to integrate these smart devices in new
applications and IT processes. While these are important and essential aspects of IoT-related
research, the IoT@Work project, introduced in this paper, concentrates more on the problem
of allowing devices, machines, and objects to interact with each other without relying on
human intervention to set-up and connect the distributed systems purposed for industrial and
factory automation applications.
IoT@Work coordinated by Siemens started in mid 2010 and will run three years with the final
goal of designing and implementing an architecture enabling a much more automatic
configuration of devices, networks and middleware components. This should significantly
improve flexibility of industrial networks while still guaranteeing the deterministic behaviour
needed in those application domains. Industrial Networks - by this we mean control networks
in e.g. manufacturing, SCADA, energy control and more - have a great diversity, so the
project concentrates on manufacturing and automation domains. To bundle the competences
needed for this tasks, we have a consortium which provides a wide range of expertise in this
area: Siemens Corporate Research from Munich, Germany coordinates and provides
industrial communication and security knowledge. The FIAT research centre (CRF)
introduces domain know-how from the automotive area and will provide its facilities to
demonstrate important developments of the project. TXT e-Solutions, an Italian SW company
will bring in its experience in industrial IT systems. The European Microsoft Innovation Center
(EMIC) from Germany contributes to security, remote maintenance and cloud computing
issues. Another partner with significant automation experience is the Industrial IT Institute
(inIT) from Germany and finally the City University London will play a major role in designing
modern SW architectures and service oriented middleware for the project.
This paper reports on the findings of the first project phase where requirements have been
extracted by studying real-world scenarios and by considering recent trends in technology
and markets. While these first results hopefully are already valuable information for the
reader, on goal of this publication is also to initiate a dialog between the IoT@Work project
and the interested readers.
The paper is structured as follows: Section 2 briefly summarizes the project focus and the
questions arising in this context. After this, related work is outlined in Section 3. Then we
outline in Section 4 the methodology for deriving requirements from scenarios and from nonautomation specific global trends. Section 5 explains important requirements identified in this
phase and discusses some of the consequences. Section 6 briefly summarizes and outlines
the upcoming project steps and concludes this paper.
2 Project Focus
Wikipedia states: "...the Internet of things, also known as the Internet of objects, refers to the
networked interconnection of everyday objects. It is described as a self-configuring wireless
network of sensors whose purpose would be to interconnect all things..." [2]. In the public
opinion this is often confused with "has a RFID".
For us, this is only half of the truth. We believe not only sensors (or actuators) are "things" but
also infrastructure components such as network components or complete sub systems
assembled out of many smaller things will play an increasing role. Also concentration on the
wireless part would limit the scope far too much: the wireless clouds are - as of today connected via wired networks and things are controlled by and interact by complex IT
systems. Thus the project tries to close the gap between the enterprise IT systems and the
end devices (aka "things"). We also feel that infrastructure components can - and should - be
handled in the same ways as the things. Another part of the term "Internet of Things" is
apparently - Internet. This means we will take a closer look on Internet technologies, that is
mainly the Internet Protocol (IP), the Industrial Ethernet (as a close counterpart and
complement of IP) and the Web Service paradigm.
IoT plays a role in many, if not all domains of our live and economy. While we are aware of
this fact, we felt that this scope is by far to broad for a smaller research project. Instead we
focus on a domain which is undoubtedly one of the most important for the European industry:
automation and manufacturing. Not only that we have a huge amount of networked devices in
all sizes around a factory. We also have a broad range of other IoT technologies supporting
i.e. the factory-internal flow of goods and finally we have a set of IT applications making use
out of the information those things produce, i.e. the Enterprise Resource Planning (ERP) tools
or the network management.
In the project preparation phase we found several issues in this automation world which must
be addressed in order to meet future requirements. These are mainly new security
challenges, the need to minimize down times in case of failure and changes and the demand
for secure and cost-efficient management solutions.
Thus the project concentrates on the factory automation domain and here especially on
communication related aspects. That is mainly the control level and process control level of
the automation pyramid (see Figure 1). With this focus in mind the project aims at enabling
1
plug and work supporting a flexible and secure business.
Figure 1 – Component and network topologies at each level of the manufacturing pyramid
IoT@Work focuses on developing self-configuration mechanisms, enabling what we call
secure plug and work IoT, whereby devices are auto-configured and ready to co-operate with
each other as soon as they are plugged into the factory network.
Figure 2 - Orchestrating Advanced Communication Services - decoupling automation
application/controller programming from network operations
In general, automation applications have more stringent communication requirements, when
compared with traditional Internet applications. To fulfil these requirements today, all layers
(including the lower communication layers, e.g., physical, data link and network layers) are
directly addressed by the automation management systems. This increases substantially the
effort required for the configuration of such a network and means that the operator must also
be a communication expert. To reduce the complexity of providing the highly sophisticated
communication services required, the automation programming needs to be decoupled from
the network operation, through the introduction of a management and orchestration layer
(shown in Figure 2). This layer represents an abstraction of network resources to the
1
Plug and work differs to the plug and play that insinuates audio/video or home appliances.
The plug and work refers to devices or things used in industrial and production systems.
automation programming domain and is capable of offering on-demand communication
services (e.g., messaging and event services, robust and reliable communication, reservation
mechanisms, differential security services, etc.) to the application, while being mapped on top
of a standard and easy to deploy network infrastructure. In this way, the automation
application designer would see the network as a “black box” that offers different types of
communication services through a well-developed interface.
At the same time, the industrial network should have self-adaptive capabilities so as to be
able to respond to the requests of the applications and control processes in automation. The
interface between the two will serve not only to hide the networking complexity from the
higher application level but also to inform the network of the overall goals and safety
properties that need to be guaranteed at all times by it. The focus is made on providing
communication services on-demand and in an adaptive manner, over a shared
heterogeneous communication infrastructure, and catering for different application needs. The
described decoupling is crucial in order to realize the aforementioned Plug&Work vision.
3 Related Work
Factory Communication Domains: Networking requirements, in and around the factory
floor, differ depending on the needs of the various applications running at each level of the
automation pyramid (illustrated in Figure 1 – Component and network topologies at each level
of the manufacturing pyramid). Local and wide area networking technologies are needed to
connect the Enterprise Management Level, the Management Execution Level and the
Process Control Level; typically the required network performance is moderate. A distribution
network connects process control with local on-site controllers with high requirements
concerning QoS, including real-time capability and failover behaviour. Finally, the local onsite controllers are connected with the components at the field level next to the technical
process, where the most stringent communication requirements are found. Standard
Ethernet/IP can be used at the enterprise management and manufacturing execution levels.
Today, to fulfill the more stringent requirements of networked control systems, some special
Ethernet variants are typically used. Even so-called Isochronous Real-Time (IRT)
communication, which is characterized by a maximum jitter of 1 microsecond for data
delivery, is often required. Today IRT-quality only can be achieved either with a field bus type
of technology, such PROFIBUS, INTERBUS, Devicenet, CAN, etc. - which both have
significant restrictions in terms of scalability and maximum available bandwidth - , or some
significantly adapted Ethernet, such as EtherCat or PROFINET (further details are given
below).
Industrial Communication Technologies: In recent years packet-switched Ethernet has
found its way into the field level of automation and control systems replacing specific bus
systems [6]. Since the common Ethernet technology cannot fulfill all the industrial automation
requirements, various adaptations have been developed ending in an large number of
Industrial Ethernet types, like PROFINET, EtherCat, EtherNet/IP, Modbus/TCP and more
[12][11][10][9].
Examples of improvements of the original standard include adding real-time and isochronous
real-time communication capabilities, or advanced failover mechanisms to minimize outage
times. When looking closely at the improvements, they could be separated in two groups: (i)
technologies that obtain highly deterministic communication by synchronizing the network
nodes and thus synchronizing the scheduling throughout the network, (ii) technologies that
focus on over-dimensioned networks with advanced packet scheduling schemes in the nodes
but without synchronization of the network nodes. In general the second approach will not
deliver determinism due to its pure packet-based architecture but in a large number of cases,
this approach is expected to deliver sufficient communication network quality [10].
The wide range of more or less incompatible solutions is due to a wide range of requirements
- from long distance, low rate SCADA networks to real-time capable machine control, from
tiny analogue sensors to powerful servers, from simple monitoring to complex automation
processes. The common denominator of those solutions is the use of Ethernet (in many
cases with special extensions) and the use of standard TCP/IP (IPv4). However, the different
variants are not compatible when it comes to real-time or other specific features. In some
cases even special hardware is required for full functionality (e.g., the ERTEC ASIC for
PROFINET IRT communication shown in [7][9][10][11][12].
Figure 3 - Classification of industrial Ethernet protocols [8]
Network Planning and Deployment: After the planning of an automation application has
happened, the requirements on the communication relationships are identified. These
requirements are the basis for selecting network technologies, topology and protocols. The
required redundancy is also to be considered accordingly in this network planning process.
The configuration of the network details both, device level and intermediate networking
devices. The development of a detailed network configuration is today typically done with the
help of a vendor-specific tool for the chosen industrial networking technology. E.g., the “Step
7”-tool provided by Siemens is used for a planning and configuration of PROFINET networks.
All this requires a good knowledge of the network details (from the details of the topology. The
offline planning and testing results into configuration files which are uploaded or plugged into
each physical device separately. Moreover, when setting up the communication network,
many actions are to be performed manually:
•
Pairing of a physical device with a name or network address used in the
Programmable Logic Controller (PLC). This step is typically done mostly manually
after mounting the device. The device ID used for this purpose can be an Ethernet
(MAC) address.
•
Configuration of the respective device for network access (i.e. assignment of an IP
address) and application specific parameters. This step may use some protocols,
such as e.g. DHCP [15] and/or DNS [14][14] in conjunction with semi-automatic
configurations, e.g., using memory cards holding additional configuration parameters
or by a tool-based remote configuration after the network is operational. This process
may differ significantly from standard to standard or between various solutions.
•
Resource allocation for QoS set-up, i.e. configuration of the communication paths
between various nodes of an automation network. An example could be the
reservation of Industrial Ethernet transmission cycles in network switches.
After initial installation and initialization, today's automation applications assume a stable
network without changes. In case of changes of the communication network topology, device
replacements or failures, the steps above must be at least partially repeated. As of today, all
these steps again include many manual actions and they are error-prone if some manual
reconfigurations are required.
Network Monitoring and Management: An important part of deployment is monitoring and
management of the running network. Today's tools are already able to automatically detect
connectivity and many network related parameters of devices using SNMP [16]. In case of
failures, alerts can automatically inform a supervisor. However to make SNMP secure even
for remote administration and maintenance either IPSec or Access Control Lists need to be
used which typically is quite cumbersome. Thus, today's devices with more intelligence (i.e.
an I/O module) may also provide some additional remote login or Web-based interface (http)
for this purpose. SNMP is also not well suited for a fast and frequent polling of device
properties.
Plug and Play technologies: Many network protocols (e.g., Rapid Spanning Tree Protocol,
Media Redundancy Protocol, Interior Gateway Protocols) are defined in a way that after some
basic configuration (i.e. activation and basic parameter setting) they automatically start the
negotiation process with their neighbors and e.g. start to exchange reachability information.
But to realize an end-to-end communication service, typically many protocols are involved
and need to be used in an intelligent way. Thus the orchestration of numerous such
communication services fulfilling a given traffic matrix with specific requirements on the
communication relations needs to be done manually today.
On the application layer in the enterprise/home network scenarios UPnP (Universal Plug and
Play) - which is built on a stateless broadcast protocol (http over UDP) - is used for autoconfiguration or for service location. But even on the higher layers this technology does not
fulfill the industrial requirements and thus cannot be directly used in the automation
environments.
4 Identification of Requirements from Real-World Scenarios
The methodology chosen to identify the IoT@Work requirements is to have multiple views on
existing industrial systems and scenarios. With the help of the scenarios, the system
constraints and details can be identified and formulated into requirements. Also the
technological approach proposed in the project can be better argumented.
This approach and process will prove in the immediate future as an effective way to both
refine the performed analysis and, in parallel with the architectural and services design
activities, to expand/deep investigation areas and aspects.
Networking requirements, in and around the factory floor, differ depending on the needs of the
various applications running at each level of the automation pyramid (see Figure 1).
Local and wide area networking technologies are needed to connect the Enterprise
Management Level, the Management Execution Level and the Process Control Level;
typically the required network performance is moderate. A distribution network connects
process control with local on-site controllers with high requirements concerning QoS,
including real-time capability and failover behaviour. Finally, the local on-site controllers are
connected with the components at the field level next to the technical process, where the
most stringent communication requirements are found. Standard Ethernet/IP can be used at
the enterprise management and manufacturing execution levels. Today, to fulfil the more
stringent requirements of networked control systems, some special Ethernet variants are
typically used. Even so-called Isochronous Real-Time (IRT) communication, which is
characterized by a maximum jitter of 1 microsecond for data delivery, is often required. Today
IRT-quality only can be achieved either with a field bus type of technology, such PROFIBUS,
INTERBUS, Devicenet, CAN, etc. - which all have significant restrictions in terms of scalability
and maximum available bandwidth - , or some significantly adapted Ethernet, such as
EtherCat or PROFINET.
As of today, such factory networks will stay stable after planning for longer periods and often
must run non-stop without any failure as each stop in the factory will cause high costs.
To estimate how those networks will look in mid term and far future, it is essential to analyze
current shortcomings and to indentify trends which may impact those networks.
The IoT@Work process to analyze these issues is as follows:
Collect scenarios from existing installations
18 telegram style scenarios where collected in the initial phase. All of them where covering
true stories, some from literature, some from investigations of the project partners. Main focus
was to find stories where information on important requirements, problems or non-optimal
issues was available to identify the points to optimize. Those telegrams came from very
different automation domains such as brewery automation, automotive manufacturing,
SCADA and more. One common denominator was the use of some industrial Ethernet
standards.
Prioritise and condense
To further process the telegrams from step one, criteria for prioritisation where chosen.
These where mainly: scenario should be related to manufacturing, should describe
aspects addressed by the project, a reasonable high level of complexity and finally a
reasonable amount of info must be available. The telegrams where weighted using those
criteria and then three artificial scenarios where constructed. Each of these scenarios
bundled some of the telegrams into a new story, but still rooted in the real world. These
new scenarios where:
1. Agile Manufacturing: a production approach heavily based on the availability
of manufacturing support technology that can be easily reconfigured to
quickly respond to market changes still providing full control of production
costs and quality. Agile manufacturing is universally considered as the next
step after the lean production methodology.
2. Remote Maintenance: this scenario helps analysing situations in which
external providers (e.g. robots/tools providers) have direct access to devices
or data within the production sites to assure production continuity for example
doing preventive maintenance.
3. Multi-Site and Large Scale Manufacturing: representative of large production
arrangements where many different production sites have to be coordinated
and integrated. This scenario is comprehensive of both situations in which the
different sites belong to the same producer, as well as situations in which the
involved sites belong to different producers pertaining to an highly integrated
supply chain.
Analyse and identify the initial requirements
The initial requirement collection is centered on the three scenario clusters “Agile
Manufacturing”, “Large Scale Manufacturing”, and “Remote Maintenance”. These
scenarios provided some details of the system model and underlying infrastructure found
in common practice and state of the art.
Based on the initial description of the system details, a first list of improvements, needs, and
detailed changes have been extracted and formulated as requirements. To analyze deeper
the scenarios, a list of areas of interest was formulated and used to identify and evaluate the
requirements:
•
(Re)Configuration costs: costs for the initial set up of a new system, changes
(upgrades, replacements, modernization) and reparation.
•
Decoupling network and automation; refers also to the currently tight coupling
between planning and roll-out
•
Communication network resource abstraction and clear interface to a networkagnostic application: the configuration effort has to cater for the application needs, on
the one hand, while removing the need to be an expert in both networking and
automation programming.
•
Realization of Communication Services: development of concepts and eventually
protocols to realize the mandatorily required communication services.
•
Plug&Work: By the term Plug&Work we refer to the ability of devices and network
components to auto-configure themselves according to the needs of the automation
applications. Covers also the re-configuration in case of replacements. Plug&Work
shall work in multivendor environments and massively reduce the manual actions
required, and, by so doing, it will also reduce both the overall downtime and the
number of errors. May also have security impact.
•
Naming and Addressing: are there any specific naming and addressing issues?
•
Secure Service Access: is there a need for secure remote access and are there
mechanisms for secure service access of third parties in a protected domain such as
the factory floor.
•
Secure Communication: Analyze the applicability of currently used and deployed
security protocols or security frameworks in industrial environments. If necessary,
define extensions for use of protocols in industrial networks. Adapt candidate
protocols to industrial communication if needed by developing bridging technologies.
As a complement to the scenario driven methodology, global trends from various different
areas have been analyzed to find drivers and inhibitors for the future automation. This
included the possible impact from the so-called mega trends but also from the evolution of
devices and related technologies.
By matching the areas of interest to the scenarios and analysing the available information,
finally a list of first requirements could be produced. These requirements - in total around 25 where again clustered and prioritized according to the relevance.
5 Requirements for future Automation and Manufacturing Networks
Each of the three scenarios produced a list of high level initial requirements. For the Agile
Manufacturing this gave:
•
Allow system extensions or changes at run-time as long as the production subsystem is not affected
•
Support fast and controlled re-initialization after systems extensions or changes in
off-line system state
•
Support reconfiguration of network paths in the case of path failures, through
redundancy protocol (but more on-demand)
•
Fast network bootstrapping
•
Fast device configuration changes for migration
•
Less manual configuration effort due to any type of changes
•
Automatic decision making to deal with failures
•
Graphical network configuration system (e.g. drag & drop device configuration)
and graphical network maintenance system
•
Fast and reliable semantic addressing (avoid static IP)
•
Remote maintenance: including discovery of device or component that is root-cause
of a failure (read only access)
The list of requirements for the Large Scale Manufacturing is:
•
high availability: includes redundancy and well-structured, independent sub
networks but also aspects such as fast and easy replacement of defect equipment.
•
self-sufficient operation of sub systems: for the installation, configuration and
testing, the respective parts of the automation network should be capable of running
on their own without the backbone.
•
cloneable: as smaller or larger parts of the installation will be installed multiple times
in the factory (i.e. many identical welding cells), it should be easy to copy the
configuration and control SW.
•
extensible: it should be easily possible to add new services, new technologies, sub
systems or devices. This will e.g. affect the number of IP addresses needed for the
network.
•
secure: the enterprise should not be affected by a malfunctioning automation part
and vice versa.
•
easy-to-use configuration and management tools.
•
remote diagnosis: for external support, a remote access to the relevant parts should
be possible.
•
companywide access: devices and services should be reachable from anywhere in
the company. This requirement mainly addresses issues considering address rooms
(NAT or flat IP address space) and probably structuring of security realms.
Requirements from the Remote Maintenance scenario are:
•
Identification of devices: before maintaining a device, it needs to be clearly
identified in a distributed system. Identification here includes e.g. point-of-attachment
(IP/MAC address) to the network, device name and more to distinguish between
many similar devices.
•
Condition Logging/Monitoring: Detection of failures/maintenance needs by
identification of the device condition.
•
Secure and remote access, allow access of authorized people only. This also
implies that there must be means of properly manage authorizations and related
security properties.
•
Replacement of devices requires a coordinated action between on-site and remote
support.
•
for safety reasons, all actions from remote management must be controlled by a
local operator (i.e. ensure that remote management does not interfere with normal
operation)
As a side note from this analysis, we see that there's a need to manage SW for industrial
devices (i.e. for security updates). But operators fear changes in the SW as this on the one
hand could lead to unpredictable situations if incompatible versions occur and on the other
hand this is a step which again may require pausing the system which is costly.
There where other requirements which could partially also be identified in the scenarios, but
are more coming from the market and global trends:
•
Lack of skilled people requires to organize the complexity of the system in a way
that experts can act more efficiently. For example someone who installs devices
should not need to have network or fieldbus knowledge. One way to achieve this is a
clear separation of different realms and a good tool support. Another way could be a
better use of remote support.
•
Shortage of rare materials: today's high-tech industry increasingly depends on the
availability of certain rare materials, i.e. antimony, beryllium, cobalt and more. This
will become a major driver for recycling and modernization (rather than complete new
products).
•
Ever increasing number of networked devices must be handled and requires
scalable network structures and addressing schemes (i.e. IPv6) and clear separation
of security domains.
•
Global Warming seen from the automations point of view mainly affects energy costs
and the companies reputation. We see that this again requires more flexible
production, i.e. to enable energy savings or to enable cost reductions in times of high
energy costs. It is also an argument for modernisation.
6 Conclusions
The project IoT@Work has analysed a number of automation related scenarios which clearly
show the need for evolutionary steps towards more flexible automation networks and the
need to cut down costs by means of less outage times and less management efforts. There is
also an increasing need for clear security strategies and scalable and automatic configuration
management for both SW/Firmware and devices (network and end devices).
Protocols and concepts found in the Enterprise IT or in home networks cannot be applied
unchanged due to the strong requirements of real-time support or resilience found in many
SCADA or manufacturing environments.
Some non-technical requirements and constraints further complicate a potential solution:
•
there are far too many standards which are only partially compatible
•
the installed base of often very expensive devices demands for concepts to allow
smooth modernisation
•
lack of skilled people and maintenance costs will drive remote management services
which - among other consequences - requires proper means of managing security
Enhancing flexibility of a production needs to change and enhance many issues of a process.
IoT@Work concentrates on the factory floor networks which can be seen as an enabler for
other means of improvements. From the scenarios that have been studied, technical
requirements here include:
•
support of clonable sub networks; this affects addressing concepts and configuration
management
•
modern security concepts, i.e. certificate instead of logins, network access control,
ability to update SW without affecting the operation
•
enhance scalability for future scenarios of even larger number of devices. This again
affects addressing issues, network topologies but also middleware aspects, i.e. preprocessing of data in the field
As a final conclusion, to drive the evolution of automation networks towards higher flexibility, it
is mandatory to understand the needs and shortcomings of current networks and the near/mid
term trends. As such the IoT@Work project will develop advanced solutions which are deeply
rooted in "real world scenarios" but still use modern and new concepts for a clear evolution.
Acknowledgements:
th
This paper is a result of the European Project IoT@Work funded under the 7 framework
program FP7-ICT-Call5 with the grant number ICT-257367. The authors of this paper would
like to thank the project partners that have contributed to the work mainly, J. Claessens, H.-J.
Hof, M. Ippolito, J. Imtiaz, J. Jasperneite, C. Kloukinas, S. Mechs, I. Siveroni, D. Rotondi, H.
Trsek, M. Villa, G. Völksen.
7 References
[1] M. Villa, D. Rotondi, M. Comolli, C. Seccia, H.–P. Huth, A. M. Houyou, C. Kloukinas,
H. Trsek, J. Claessens, IoT@Work Plug&Work IoT Requirement Assessment and
Architecture, public project deliverable, 30/11/2010, https://www.iot-at-work.eu/
[2] http://en.wikipedia.org/wiki/Internet_of_Things
[3] J. Jasperneite, “Echtzeit-Ethernet im Überblick”, in atp - Automatisierungstechnische
Praxis(3), March 200
[4] J. Pinto, “The Future of Industrial Automation”, Automation.com, December 2004
(http://www.jimpinto.com/writings/automation2005.html)
[5] VDI/VDE-Gesellschaft, “Automation 2020 - Bedeutung und Entwicklung der
Automation bis zum Jahr 2020 - Thesen und Handlungsfelder”, June 2009
(http://www.vdi.de/fileadmin/vdi_de/redakteur_dateien/gma_dateien/AT_2020_INTER
NET.pdf)
[6] Decotignie, J.-D., "Ethernet-Based Real-Time and Industrial Communications,"
Proceedings of the IEEE, vol.93, no.6, pp.1102-1117, June 2005.
[7] Jasperneite,
Jürgen:
Echtzeit-Ethernet
im
Automatisierungstechnische Praxis(3), March 2005.
Überblick
-
in:
atp
-
[8] J. Jasperneite, J. Imtaiz, M. Schuhmacher, K. Weber, A Proposal for a Generic RealTime Ethernet System, IEEE Transactions on Industrial Informatics(5) p.: 75 -85, May
2009.
[9] P. Brooks, EtherNet/IP Industrial Protocol White Paper, Oct. 2001. URL:
http://literature.rockwellautomation.com/)
[10] Paul Didier, Fernando Macias. Ethernet-to-the-Factory 1.2 Design and
Implementation Guide. Cisco Validated Design. July 22, 2008. (URL:
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns822/landing_ettf.html)
[11] Peter Neumann, Communication in industrial automation—What is going on?. Control
Engineering Practice. Elsevier, Vol. 15 (2007) pages 1332–1347
[12] PROFINET/PROFIBUS International (PI). (URL: http://www.profibus.com/)
[13] IETF, An Architecture for Describing, Simple Network Management Protocol (SNMP)
Management Frameworks, RFC 3411. Dec. 2002
[14] IETF, Domain Name System (DNS), RFC 5395, (also explained in URL:
http://en.wikipedia.org/wiki/Domain_Name_System )
[15] IETF, Dynamic Host Configuration Protocol (DHCP), RFC 2131, (also explained in
URL: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol )
[16] IETF, Simple Network Management Protocol (SNMP), RFC 4310, (also explained in
URL: http://en.wikipedia.org/wiki/Snmp/)