case study: from legacy to connectivity migrating ... · pdf filecase study: from legacy to...
TRANSCRIPT
Case Study: From Legacy to Connectivity Migrating industrial devices into the world of Smart Services
Peter Priller, Andreas Aldrian
AVL List GmbH
H. List Platz 1
8020 Graz, Austria
Thomas Ebner
evolaris next level GmbH
Hugo-Wolf-Gasse 8/8a
8010 Graz, Austria
Abstract
Europa has launched multiple initiatives and
research projects to remain competitive in a globalized
world and keep industry and manufacturing on-shore.
Funded by EU and member countries, project
ARROWHEAD[1] focuses research and innovation for
collaborative automation using interoperable services
for smart production, to improve quality, efficiency,
flexibility and cost competiveness. This includes an
important new aspect called “Smart Services”, which
aims to apply SOA to maintenance and service of
production systems and its parts, which still carry a huge
potential for further gains in cost and energy savings.
However, there will be no “big bang”. How can we
turn present-day variety of diverse, specialized, and
legacy loaded embedded systems into connected, SOA
based cooperating participants of the Internet of Things
(IoT)? This case study portrays the solution followed in
ARROWHEAD WP1.1, for devices used in end-of-line
(EoL) test systems in automotive powertrain production.
1. Introduction
Vehicle development and manufacturing is an
important part of Europe’s industry. Safety, fuel
economy as well as emission and CO2 reduction are
driving factors, requiring highest quality and efficiency
levels in production. Every engine, every powertrain
undergoes an extensive set of tests right after production
(EoL = end of line testing, see figure 1), to ensure
adherence of quality levels and stringent emission
legislation. Such EoL tests typically consist of a variety
of specialized devices, analyzing fuel consumption,
optimizing engine strategy controlling e.g. exhaust
gases, calibrating electronic control unit (ECU) data to
guarantee ideal drivability and more. As these tests need
to be in sync with the production cycle, throughput
performance and availability are paramount. Devices
must meet highest industrial quality goals, and
sophisticated maintenance strategies aim to prevent
downtime as much as possible.
Service needs of devices typically depend on multiple
factors in addition to operating time, and are often
influenced by operating conditions like temperatures, gas
flows, peak load, load distribution, etc.
However, maintenance cycles are usually selected and
started by service personnel typically relying on “rules of
thumb”, which might be based on average usage data,
and are therefore often overly conservative.
Figure 1. EoL testing in engine production
AVL’s Smart Service initiative aims to optimize
maintenance, by analysing actual usage, contamination,
stress, and other indicators, in order to calculate actual
state of sensors and devices, characterizing the real
wear-out more precisely.
It allows manufacturer, user and maintainer to get
exact data on product usage and to derive services
activities from product usage that are:
• Pro-active upcoming events/break-down
prevention
• Pre-emptive necessary consumables for
operation
• Reactive predefined reaction patterns on break-
down
It improves decision making regarding maintenance
and replacement procedures as well as scheduling
calibration cycles. In order to guarantee highest system
availability, the smart service concept optimizes
planning, scheduling, and even contracting required
service and maintenance activities in time. Smart
services in this context are implemented as IT network-
based services [2].
It allows having device service intervals negotiated
more or less autonomously between production system
and maintenance organizations, trying to find an optimal
schedule, satisfying constraints on availability, cost,
material use and energy consumption.
Figure 2. Smart Services: Example process flow
Today’s complex cooperative production lines
typically involve more than one player.
Automotive original equipment manufacturers (OEM)
might commission different plant owners to build
engines using EoL testing equipment leased by a third
partner, and maintained by a fourth specialist, potentially
even pools of several companies.
ARROWHEAD concepts address such complex sets
of N:M relations and suggest an unified yet flexible way
to design service-oriented interaction in such highly
inhomogeneous systems for both hardware and stake-
holder side. However, as we will show in the following
chapters, a major challenge lies in applying these
concepts to a world of long-time established products, in
industrial environments which were up to now isolated
from the IoT.
Smartphones and other consumer gadgets have made
us accustomed to enjoy online connectivity for any
device at any time. Mobile networks allow creation of
powerful applications, combining small, power efficient,
wearable devices in our hands to act as always present,
handy front-ends on one side with the power of large
data centres and powerful computing resources situated
anywhere in the world.
In contrast, communication and computing abilities in
recent industrial production EoL automation systems
might be quite constrained. Measurement devices like
gas analysers, emission measurement benches, smoke-
meters, fuel and oil consumption etc. are discrete,
specialized devices, and have been designed for stand-
alone use (e.g. semi-manual testing), or alternatively are
only capable to be integrated in automation systems
(AS), managed by programmable logic controllers (PLC)
or sophisticated systems like AVL’s PUMA Open.
However, described devices are usually built with
resource-constrained embedded controllers, offering just
basic connectivity over field busses like CAN, Profibus,
or Ethernet, in which case typically only simple TCP/IP
based communication or proprietary protocols are
supported.
How can we get today’s generation of devices to
become first-class citizens in a web-service enabled
world? This case study summarizes results after year one
in WP1.1 of Arrowhead, addressing “Smart Services”
for EoL automotive test systems, shown as example in
figure 2.
To benefit from coordinated and managed services
described above, technical solutions were needed for
providing efficient, secure and reliable connectivity to
ES and cyber physical systems (CPS) used in EoL
testing, and to build supporting software service
infrastructure. Smart solutions shall enable migration for
today’s devices; new architectural concepts shall be base
for next generation devices; and at the same time, smart
concepts are needed to guarantee interoperability and
consistency for any mix of generations, which – as this is
the domain of industrial invest goods - spans life cycles
of a decade and more.
For a complete view, we will analyse these aspects
• Legacy
• Connectivity
• Security
• Privacy and Transparency
• Safety
• Usability
• Efficiency
2. Legacy
AVL is the world's largest privately owned company
for development, simulation and testing technology of
powertrains. The Instrumentation and Test Systems
division (ITS) is an established manufacturer and
provider of instruments and systems for powertrain and
vehicle testing, including combustion diagnostic sensors,
optical systems as well as complete engine, powertrain
and vehicle test beds. Real-time (RT) simulation systems
simulating environment and auxiliary devices are needed
to allow a unit-under-test (UUT) to operate in typical
scenarios.
As a result, such EoL test-systems are systems of
systems (SoS) combining intelligent devices, typically
managed by one or more AS. All these systems interact
and communicate with typical SCADA networks and
bus protocols (like CAN, Profibus, IEEE-1394,
EtherCAT, standard Ethernet, …)
For decades, such measurement devices have been
developed, improved, and optimized for use in
development and production of automotive powertrains.
Electric/electronic system and software design of such
devices were guided by measurement principles,
durability and robustness constraints of the industrial
environment, efficiency and price. A typical
measurement device may be intended for stand-alone
use; alternatively it may join a usually isolated, local
network, used to connect devices to some automation
system, which acts as management system and data
aggregator. Many such device types are well established
in the market. In order to support full-fledged smart
services, these devices need to extended connectivity.
Legacy systems typically provide little means for
direct connectivity to access remote services over the
internet. Existing communication interfaces based on
field bus technology or point-to-point Ethernet have
communication implementations constrained to the bare
minimum of the 7 OSI layers; devices might just support
layer 1 and 2, plus some parts of 3 and 7. This suffices
for local networking, typically isolated to each EoL test
station, but provides no support for reliable, secured
communication across networks.
Devices typically implement certain commands
issued by human operators or AS, like “flow calibration
gas”, “clean”, “calibrate”, “measure” etc., and respond
with status and measurement values. Multiple devices
like multi- analyzer modules for emission gas analysis
might be combined with additional systems like
measurement benches, extended by sampling
conditioning and other sub-systems, thus forming simple
SoS arrangements.
A widely used communication protocol for such
systems is the "AK protocol", named after the
standardization body “Verband der Automobilindustrie
e.V. / Arbeitskreis Techniken zur Standardisierung der
Abgasmessung", was designed as simple protocol
without supporting sophisticated Authentication,
Authorization, Accounting (AAA). AK protocol
supports communicating commands and values in a
serial way, originally based on V24/RS232 connections.
Supporting 7 bits per character without hardware
handshake, it was designed relying on standard ASCII as
representation, guided by software handshake. To
address multiple nodes, a simple channel number is
supported, with '0' indicating a broadcast to all (eg:
"SREM K0"). Commands are grouped into control
(starting with "S", eg. SREM = change to remote mode),
Request (starting with "A", like ASTZ = request device
state) and configuration (starting with "E", e.g. "ESYZ"
for setting system time)
Devices are addressed in a point-to-point topology,
i.e. a single master (usually represented by a test
automation system) operates one or more slaves (i.e.
measurement devices).
AK-protocol is still de-facto standard in many
automotive testing facilities; however, it is quite obvious
that it is not suitable for direct use for the targeted web-
based smart service concept, using open network
connections.
Computing resources in described measurement
devices, often provided by standard 8 bit or 16 bit micro-
controllers with just enough memory and little
expandability, are typically too constraint to implement
full end-to end connectivity, not to mention requirements
like security, auditing, automatic service negotiation etc.
Typical user interfaces are not designed to support
complex connectivity configuration, either.
A complete redesign of such devices from ground up
is not feasible – for commercial reasons, but also as
some devices have to undergo detailed certification
routines by authorities, taking time and effort. Therefore
we had to find concepts which allowed implementation
of smart services, requiring devices to be able to
communicate via different network hierarchies including
open and unprotected internet, by extending or
augmenting existing designs. At the same time it needs
to define groundwork for new architectures of upcoming
generations of such devices. As an additional challenge,
the possibility of migration between both worlds needed
to be taken into account.
Figure 3. Zone Partitioning
After an intense requirement engineering phase,
which included detailed threat model analysis described
in the section on “security” below, the WP1.1 team
defined the required zones (see figure 3) and suggested a
concept of a modular extension to existing devices,
called mediator.
A mediator (see figure 4) includes necessary
computation and communication resources, as well as
extensions to implement security and transparency, like
hardware-implemented unique-ID, NFC/RFID
interfaces, certificate storage, hardware encryption
support etc.
Among other features, the mediator acts as a
gateway, communicating with the legacy device using
legacy interfaces and protocols, like the AK protocol on
one side, while providing full networking capabilities on
the other side. This allows access to web-based services
using internet connections, either by plugging into
existing in-house LAN (“Intranet”) as a gateway to the
internet, or by providing means to connect independently
of in-house IT using 3G/LTE connectivity on-board.
Such connectivity bears considerable threat potential
for data and IT infrastructure of the owner, therefore
security became primary concern in its design (see
section “security”).
3. Connectivity
Smart services shall enable semi- or full automatic
service activities like device calibration or maintenance
activities. Different approaches are available to
communicate smart service information:
• autarkic: no direct network communication;
this usually requires manual activities, e.g. a
technician to read displayed status information,
which is then entered into service/maintenance
IT systems.
• Semi-autonomous:
if permanent internet access is not available or
not desired, ad-hoc connections can be
established by certified maintenance personnel
if required, using e.g. mobile phones as
gateways, authorized and communicating via
NFC with the device. After manually
establishing the connection, all other
communication is done automatically.
• autonomous:
communication is point-to-point and done as
machine-to-machine (M2M), between device
and service provider, with no human interaction
required.
The suggested architecture supports all three
approaches, with a strong favor on autonomous systems
to enhance productivity.
In case a measurement device supports communication
to other devices and especially to a management system,
connectivity is typically implemented as standard
fieldbus (like CAN or Profibus) or standard Ethernet
connections (sometimes still operating at 10 Mbit/s).
Current systems are designed to assume fully
trustworthiness for any such connection; therefore, a
concept to extend communication to internet based
services must take this into consideration.
In case a standard field bus is used, constraints from
data rate (e.g. CAN: max. 1 Mbit/s total) and packet
length (CAN: max. 8 Bytes) prompted specifically
designed protocols. In order to convert this to IP based
communication used for Web-based services,
considerable translations need to be performed in
gateways.
In a more complex scenario, several devices are
interconnected by a local network, operated by an
automation or management system. Pooling devices and
subsystems within one test unit allows cooperating
locally and fusing data to derive general context
information. This can be used e.g. to analyze and detect
specific modes of operation, thus allowing to derive
additional information regarding maintenance needs.
Alternatively, one node (typically the automation
system as being the most capable one) can act as data
concentrator and take on the role (or at least parts of it)
of the mediator device if required.
Smart services rely on direct interaction between
devices and web-based services, e.g. for real-time
tracking of device condition from remote entities, like
maintenance and repair centers.
Therefore ways to interact and communicate with the
device across multiple layers and hierarchies of
networks, from a cloud service through internet, GSM or
other networks directly to the device, optionally being
routed through customer SCADA or other automation
systems, using existing technologies down to fieldbus
systems need to be supported.
Figure 4. mediator
This exceeds typical device capabilities by far (see
section “Legacy”), and is therefore carried out by the
add-on mediator device. Besides networking resources,
the mediator includes also reasonable processing power
to implement management of heterogeneous, distributed
networked devices, as well as security features and
client-side functional parts of smart services.
The mediator depicted in figure 4 includes three sets
of connectivity ports:
Black: directly connected to a measurement device;
these ports implement legacy connectivity, like RS232 or
CAN based AK protocol described in the “legacy”
section above. Due to the shortcomings of legacy
protocols, these “black” connections rely on trust, which
needs to be ensured by measures like physical access
control or mechanical containment etc.
Green: directly connected to other local systems, like
AS or SCADA. Similarly to “black” ports, legacy busses
and protocols are supported; however, security layers
implemented in the mediator restrict data and
information flow to what is permissible in this local
context.
Red: these ports allow connecting to the outside
world, enabling web-based smart services as described.
Depending on the operator’s IT environment, data will
be routed via Intranet, using existing cable-bound or
wireless networks, or will establish direct web access
using public mobile phone and data networks (e.g.
GSM).
3.1. Architecture Considerations
The Arrowhead framework is a collection of
matching services, interfaces and systems. The reference
infrastructure for the Arrowhead framework is by design
a highly modular setup that consists of a small set of
basic building blocks, which conceptually establish the
foundation of a suitable SOA infrastructure. Two
implementation alternatives were considered for the
architecture of the Arrowhead framework: The first
alternative consists of building blocks using web service
technology. Unfortunately, this solution does not fulfil
all security requirements of our customers, as they do not
want to open their firewalls for incoming requests.
Therefore, in the second alternative the SOA architecture
is based on publish & subscribe message queue
technology.
3.2. SOA based on Web Services
In this alternative interfaces are implemented using
web service technology[3]. This way, functional
building-blocks are accessible via standard Internet
protocols independent of platforms and programming
languages.
Figure 5 shows the different system components
communicating via web services:
The service provider “device” (A) creates a web
service for querying device specific data and can publish
its interface and access information to the service
registry.
Figure 5. SOA based on web services
The service registry (SR) is one of the fundamental
pieces of a SOA, keeping track of all services within the
service network. It stores and provides a generic
publish/discovery service for all service descriptions of
any offered services available within the service
network. All service providers must register themselves
at the registry in order to be detectable by consumers.
The service consumer (B) is a client accessing one or
more producers. In order to access the producers, the
client must first locate them by searching in a service
registry.
The authorization system (AS) or access control
policy defines whether a consumer can perform an action
on a particular producer.
The orchestration system (OS) is used to assign
several consumers to a particular service. It is planned to
use the Business Process Model and Notation (BPMN)
for specification of business processes and a Business
Process Engine for executing the business processes.
Although this solution is very flexible and already
fulfils many security requirements it cannot be used for
the Smart Service use cases due to the fact that in this
architecture the firewall at the device owner side has to
be opened for incoming requests, as the consumer (smart
services application) has to call web services at the
provider (customer) side.
3.3. SOA based on a Publish & Subscribe Message
Queue (MQTT)
As an alternative to the web service implementation a
SOA architecture based on a message queue with publish
and subscribe functionality was developed (figure 6).
Figure 6. SOA based on MQTT
Its implementation shall use the Message Queue
Telemetry Transport (MQTT) protocol, standardized in
OASIS[4]. This machine-to-machine (M2M)/”Internet of
Things” connectivity protocol provides an extremely
lightweight publish/subscribe message transport with the
benefits of [5], [6]:
• extending connectivity beyond enterprise
boundaries to smart devices,
• offering connectivity options optimized for
sensors and remote devices,
• delivering relevant data to any intelligent,
decision-making asset that can use it,
• enabling massive scalability of deployment and
management of solutions.
The MQTT protocol is based on the principle of
publishing messages and subscribing to topics. As shown
in Figure 6, MQTT messages are published by the
provider “device” (A) to topics at the message broker.
Consumer (B) in turn signs up to receive particular
messages by subscribing to a topic at the broker. The
message broker takes over the role of the service registry
(SR) and the authorization system (AS). The service
registry can be thought of as subject areas. Subscriptions
can be explicit, limiting the messages that are received to
the specific topic at hand, or they can use wildcard
designators, such as a number sign (#), to receive
messages for a variety of related topics [5]. For security
reasons encryption across the network will be handled
with SSL/TLS, independently of the MQTT protocol
itself. The orchestration system (OS) will be the same as
for the web service solution: a business process engine
based on the BPMN.
The biggest advantage of this solution compared to
the web service implementation is its ”push concept”
which doesn’t require open input ports at the device
owner side. Also, it enables a comparatively simple to
implement solution based on proven methods and
existing tools.
4. Security
Data exchanged to enable smart services might very
well include information the owner considers sensitive;
concrete measured data might reveal internals seen as
trade secrets.
Thus, smart services absolutely need secure,
trustable, robust technologies to handle data transport
and processing in a reliable – and verifiable! - way. Even
more so, as modern manufacturing processes involve
multiple partners. Plant, measurement devices and
manufactured goods might belong to three different
entities, being serviced by several independent
businesses.
This is why security, and how to proof it, became a
focal point of the mediator design in the ARROWHEAD
pilot WP1.1. Security architecture, as well as
verifiability of communicated information needs to be
demonstrable to users.
As described in the “Legacy” section, today’s EoL
test systems typically rely on local networks connecting
a heterogeneous set of devices with AS and other test
management systems, typically isolated from backbone
IT networks, and most likely with no internet access
whatsoever. Therefore, current devices were designed
without a particular need to address AAA.
An initial threat analysis clearly demonstrated
existing vulnerability of the current legacy design.
Missing Authentication: There was only little
protection against unauthorized access via service
interfaces of the measurement devices: hard-coded,
globally valid passwords offered close-to-no protection
against attackers, who could use the service interface to
modify internal configuration values or state information
like operating time counters and thus commit warranty
or tariff fraud.
Unencrypted Communication: thus, manipulation of
communication via service interface was easy to do,
since the communication links offered neither encryption
nor protection of integrity. Attacker could simply hook
up to existing communication links and intercept or
manipulate messages.
Missing data protection: measurements and other
state information were stored in devices in clear, open to
cloning and potentially even malicious modifications.
This is quite in conflict with the requirement of
autonomous smart services, relying on full internet-of-
things connectivity, using communication not only
within plant and user premises but also globally,
possibly on different kinds of networks.
It is important to mention that, different from
consumer electronics like mobile phones, industrial
applications typically have a much longer time of use
(e.g. 10..20 years). Security measures need to take this
into account. The concept includes
• Secure private channels between an embedded
device and its manufacturers server
• Secure (firmware) update capabilities
• Secure communication, but still transparent to
the owner (private/public key concepts)
• Secure, still efficient communication
(embedded systems like measurement
devices typically have rather simple
CPU’s and limited memory resources )
• Solutions allowing for wireless connectivity in
industrial plant environments as
alternative to cable-bound connections
(direct, or using e.g. dedicated routers)
• Optionally: scale-able, also energy optimized
local data exchange between ”closely
located” devices (device-to-device =
D2D, for e.g. context info)
The mediator design shall address these challenges,
using basic elements of trusted computing [7], e.g.
• unique, unchangeable identification,
• secured storage,
• secured near-field communication (NFC)
• hardware cryptography,
• secured certificate store
A sufficiently powered 32bit CPU allows
implementation of secure building blocks on higher OSI
layers, e.g.
• TLS [8],
• VPN,
• WLAN security protocols
5. Privacy and Transparency
As described in the security section, owners of smart-
service enabled devices need to be able to verify exactly
what was communicated. This includes the need to
• evaluate and prove security
• monitor security continuously during operation
To prove security and to build trust, transparency for
the owner (probing what data was transmitted when to
whom) as well as implemented security mechanisms
(preventing unauthorized data or device access) and run-
time efficiency (considering the limited hardware and
bandwidth resources) are to be demonstrated.
The architecture selected (see figure 6) allows
probing of transmitted data at any time by registering an
additional observer to topics of interest at the MQTT
broker. However, such a setup would only detect, but not
prevent unintentionally transmitted data.
Therefore, in an alternative architecture, a two-stage
broker could be implemented, with the first one located
within the premises of the device owner. This would
allow individually inspecting and approving data items
for transmission to a second-stage broker situated in the
DMZ.
6. Safety
User safety is a mandatory requirement in the design
of a test facility, thus has to be guaranteed intrinsically
by systems and their guarding subsystems, e.g. gas
detectors. By relying on such local safety guarantees we
can assume that added smart services functionality
should not cause any direct safety risk.
However, system design needs to ensure autarky and
independency of such mechanisms, to avoid any indirect
interference, e.g. caused by timing or semantics of
service requests. Special considerations must be given to
out-of-spec events, like request flooding, malformed
requests, denial of service (DoS) attacks etc., which is
typically still challenging during system verification.
Proposed architecture addresses this by defining clear,
mutually isolated zones with precisely defined and
guarded interfaces. An exhaustive contractual definition
of any interaction between these zones allows complete
verification at design- and later at runtime. However, this
implies having enough resources in the mediator
component, which is why we decided to select a suitable
32-bit processor architecture based on the ARM-Cortex
M4 design.
7. Usability
Setting up devices for smart services might involve
configuration and parameterization of networking,
security and services options. Typical devices used in
production lines however provide only limited support
for appropriate user interfaces.
The proposed mediator concept includes a NFC link
to use mobile devices (e.g. phone, tablet) running
suitable apps as a fully featured GUI to such devices.
User AAA is provided as fundamental functionality of
the mobile OS (e.g. iOS, Android), while using standard
NFC mechanism to secure the device-to-device
communication.
8. Efficiency
Smart services typically require extensions in the
devices for collecting data to allow estimation of a
current state or wear-out of parts. Such information, like
operating hours and temperature, minima or maxima of
measured values such as detected soot, characteristics
like aggregated gas flow in emission analyzer etc. need
to be gathered. Put into a suitable algorithm (e.g.
deterioration model [9]), characteristic values like part
degradation or time remaining before maintenance can
be calculated. As such models and algorithms might
require considerable processing power, they are good
candidates for being calculated in a cloud-based
infrastructure, using either commodity cloud-computing
providers, or, if users do not want send sensitive data to
the outside, in on-premises computing systems.
Therefore, the proposed mediator architecture allows
flexible allocation and balancing between on-premises
data computation and cloud-based processing based on
customer needs.
Besides processing power, centralized data processing
has the additional advantage of allowing centrally
managed model adjustments, enabling the use of owner-
specific evaluation criteria, as well as use of self-
adjusting and learning algorithms.
9. Conclusion
Innovative, IT-based Smart Services promise
significant improvements in productivity gains, energy
efficiency and waste reduction even for highly optimized
industrial setups like EoL testing in automotive
powertrain production lines. This case study summarizes
considerations on what it takes to enable an existing line
of products of embedded systems, like measurement
devices, to connect to and interact with web-based
services across different networking options.
Putting internet-connected, independently
communicating systems in the heart of a production line
is a highly sensitive topic for plant owners. A robust,
verifiable device security needs to guarantee data
confidentiality and must avoid causing any
vulnerabilities to existing IT infrastructure.
The proposed concept called mediator addresses these
concerns by partitioning networks in zones with clearly
defined trust levels, allowing backward-compatible
operation based on legacy protocols where it is
necessary, while at the same time applying full state-of-
the art protection when communicating via open
networks. The suggested SOA uses MQTT and its
broker concept to establish efficient, yet secure
communication and interaction between heterogeneous
sets of devices and web-based services, allowing
verifiability for each partner and flexible balancing of
processing and networking options.
ARROWHEAD is partly funded by the EU (FP7) and
national funding authorities like FFG (Austria).
References
[1] P. J. Delsing, “Arrowhead Project Home.” [Online].
Available: http://www.arrowhead.eu/about/.
[2] G. Allmendinger and R. Lombreglia, “Four Strategies
for the Age of Smart Services,” Harv. Bus. Rev., no.
October 2005, 2005.
[3] T. Erl, Soa: principles of service design, vol. 1.
Prentice Hall Upper Saddle River, 2008.
[4] “OASIS Message Queuing Telemetry Transport
(MQTT) Technical Committee | Charter.” [Online].
Available: https://www.oasis-
open.org/committees/mqtt/charter.php. [Accessed: 07-
Apr-2014].
[5] V. Lampkin, W. T. Leong, L. Olivera, S. Rawat, N.
Subrahmanyam, and R. Xiang, Building Smarter
Planet Solutions with MQTT and IBM WebSphere MQ
Telemetry. IBM, 2012.
[6] “MQ Telemetry Transport.” [Online]. Available:
http://mqtt.org/.
[7] “Trusted Computing Group - Home.” [Online].
Available: http://www.trustedcomputinggroup.org/.
[Accessed: 21-Mar-2014].
[8] T. Dierks and E. Rescorla, “The Transport Layer
Security (TLS) Protocol Version 1.2 (rfc5246),” 2008.
[9] S. Lu, Y.-C. Tu, and H. Lu, “Predictive condition-
based maintenance for continuously deteriorating
systems,” Qual. Reliab. Eng. Int., vol. 23, no. 1, pp.
71–81, Feb. 2007.