IoT platform

IoT platforms represent the current technical implementation of the goal pursued with the Internet of Things ( Internet of Things , short form: IoT), to network physical and virtual objects with one another and to let them work together through information and communication technologies . Along with a growing number of technically convergent IoT implementations, de facto standards emerged in the 2010s , which in turn have made the marketing of IoT platforms increasingly easier. This development is further favored by the fact that more and more devices are equipped with sensors, an embedded computer system and a communication processor for connection to a computer network. The spectrum of such so-called smart devices ranges from household appliances to transport and logistics systems to industrial plants. In the meantime, the networking of these devices means in practice their connection to an IoT platform. The platform fulfills the function of an operating system, which enables application programs to read data from the various devices on the basis of standardized Internet technologies and to send control signals to the devices. IoT platforms thus create an essential prerequisite for the connected devices, through innovative applications, to provide people with greater benefits than they are capable of in themselves.

Differentiation from platform markets

As an economic phenomenon, a platform is understood to be any institution without whose use competitiveness is reduced or market participation is even impossible. A platform economy is characterized by economically exploitable property rights to such or privileged design options with regard to such an institution. Platforms are not a new phenomenon in business. In the course of advancing digitization, however , platform companies have become the dominant manifestation of the platform economy.

In contrast, the term platform is to be understood here in an information technology sense, i.e. H. as a unified basis on which application programs can be executed and developed. Currently, the market potential of the IoT platforms is still largely untapped. The extent to which future platform markets will develop from this depends on numerous influencing factors. Among other things, the decisive factor is the extent to which successful market services are linked to specific cloud infrastructures or are integrated into the ecosystems of leading platform operators. From a purely technical point of view, IoT platforms can be operated both in a cloud and locally on their own servers ( on premises ). With Edge Computing , the IoT platform is installed on site, but this does not exclude the use of individual applications and services from various cloud operators.

Layer architecture of an IoT platform

All IoT platforms are characterized by the layer architecture shown below with an IoT hub for connecting devices and an application programming interface ( API) for developing and executing applications .

Layer architecture of an IoT platform

The IoT hub

The IoT Hub implements the platform-side endpoint for data exchange between the IoT platform and the connected devices. In principle, communication between the devices and the IoT hub can take place on the basis of any application protocol that is supported by both endpoints. Since computer networks themselves have a layered architecture, several hierarchically organized network protocols are always involved in the exchange of data (see protocol stack ). In the upper protocol layer, i.e. H. In the application layer, Message Queuing Telemetry Transport (MQTT) has become a de facto standard that is implemented in almost every IoT hub and is also used in the API. At the same time, other protocols are used on the device side that are not supported by every IoT hub, so that in such cases gateways are required for their conversion. In particular, in the industrial environment, data transmission often only takes place within the automation level, i. H. takes place in the lowest protocol layers, which correspond to a large number of different fieldbus systems (e.g. CAN , Modbus or Profibus ). In this initial situation, Ethernet fieldbus couplers are required to establish a network connection at all.

If the connectivity is established within the application layer, this does not imply that the receiver knows how to interpret the transmitted user data. The IoT hub must be able to identify individual information units within the received user data and convert them into data structures that the processing logic of the IoT platform is able to interpret semantically correct. In order for the platform to have write access to a device, the IoT hub must also be able to translate all write operations into the specific control signals of the respective device. In the case of programmable logic controllers of machines and production systems, this means writing the correct bits into the correct memory addresses. The IoT hub thus takes on the function that a device driver fulfills in an operating system. The range of device controls supported by the IoT Hub is decisive for the environment in which an IoT platform can be used meaningfully or for which application areas it is suitable.

Processing logic and data persistence

The processing logic of the platform records all data arriving via the IoT hub chronologically and makes them available to the application programming interface in a processed form. Control signals initiated on the application side are transferred to the IoT Hub for further transmission to the device controls. Furthermore, the data received from the devices are linked and compressed. Graphical user interfaces or HTTP configuration interfaces allow the maintenance of the master data and the configuration of a set of rules on which the processing logic is based. In addition, the incoming messages become complex, i.e. H. relevant event messages derived at the application level. Processing techniques such as Complex Event Processing (CEP) enable applications to be notified of relevant events in real time.

Several database systems are sometimes used in parallel to persist the incoming data. Both database systems specially designed for time series and document- oriented databases such as MongoDB are common . In order to achieve greater and faster data throughput, storage-centered, distributed database, caching and processing platforms such as Apache Ignite are often integrated into the IoT platform.

Many of the IoT platforms operated in the industrial environment offer special interfaces for mutual data exchange and interaction with third-party systems. Mostly these are interfaces to ERP systems from different manufacturers. Rules for interaction with these third-party systems are configured in graphical user interfaces and implemented by the processing logic of the platform. For faster connection of the ERP systems to the IoT platform, some providers provide so-called ERP adapters , which are implemented as modules within the respective ERP system. For the IoT platforms used in production, data exchange with ERP systems is essential because it is where the production orders for demand-oriented control of production are generated.

The application programming interface

In the application programming interface a digital, i. H. Machine-readable image of the devices connected to the IoT platform implemented. As a rule, this is the subset of a more comprehensive image of physical and virtual objects in which the devices are assigned to the physical objects of which they are part. Physical objects, such as a vehicle or a machine are characterized in that they at any time based on their whereabouts (English location can be located). In contrast, neither a location nor a device can be assigned to a virtual object, for example a delivery order.

Applications interact with the connected devices exclusively via the API. As a result of established IoT standards , the application programming interfaces of different IoT platforms show only minor differences. For this reason, applications that were developed for a specific IoT platform can, with little effort to other platforms porting . Physical and virtual objects are mapped in the API as resources that can be addressed and uniquely identified using a Uniform Resource Locator (URL). The connected devices and the time series of the sensory measured values ​​transmitted by the devices are also mapped as resources. Only the methods defined in the Hypertext Transfer Protocol (HTTP) are available for access to all these resources . They form a uniform interface for all IoT platforms and thus guarantee the structural interoperability of different platforms. The most common methods are:

• GET to request a resource
• PUT to change a resource
• DELETE to delete a resource
• POST among other things to create a resource

HTTP abstracts from a concrete representation of the resources insofar as they can be represented in any format. In principle, all machine-readable formats can be used for an API. At the same time, the IoT platforms available on the market only use JavaScript Object Notation (JSON) as the representation format and thus also guarantee the syntactic interoperability of different platforms. Application programming interfaces based on HTTP and JSON are now referred to as REST-like or REST API, although the latter term is based on a misunderstanding. REST as an abbreviation for REpresentational State Transfer actually only describes a certain form of resource-oriented architectures and not a specific protocol or format.

IoT standards

REST-like API

Every IoT platform provides a digital image of the connected devices in the form of a REST-like API for the development and execution of applications. The API usually allows read access to a list of all devices connected to the IoT platform, to a single device and to the time series of sensory measured values ​​recorded by a device. Individual devices can be addressed by specifying a universally unique technical ID ( Universally Unique Identifier , UUID for short). Read access to a device is usually application-side with the following request ( Request initiated):

GET …/devices/{deviceId}

The curly brackets symbolize a placeholder for the respective UUID. If there are no errors, the method call is answered with a data structure ( response ), as shown below as an example.

{
   "id": "ebc1822f-268e-4bdb-97b0-af1b270a12a9",
   "name": "PLC - CNC Turning Center 3",
   "description": "SIMATIC S7-300",
   "recordedPhysicalQuantities": [
      {
         "tag": "f1",
         "name": "Rotation turning spindle",
         "physicalQuantity": "frequency",
         "unit": "Hz"
      },
      ...
   ]
}

In this example, the response contains the following properties: UUID, designation and description of the device as well as an array with the physical measured variables recorded by the sensors. Each element of the array consists of a so-called tag as an abbreviation, a description of what is measured, as well as the physical measured variable and the physical unit in which the measured values ​​are recorded. The recorded time series are always list resources , the list elements of which contain the measured values. The properties of an individual list element are shown below as an example. These are a time stamp with the time of the measurement, a day for the assignment of the measured value to a measured variable defined in the device and the measured value itself.

{
   "timestamp": "2019-10-23T07:07:32.939Z",
   "tag": "f1",
   "value": "83.32"
}

In order to reduce the response times, the amount of data to be transmitted in the response should be within an acceptable range. For this purpose, the historical period under consideration can be restricted by filter parameters for the start date and the end date, which are transferred as URL parameters when the GET method is called:

GET …/devices/{id}/recordedTimeSeries?startDate=2019-10-23T07:00:00.000Z&endDate=2019-10-23T08:00:00.000Z

Furthermore, the response to read access to list resources is generally limited by the concept of pagination . Consequently, the partitioning of a list into smaller sections list is meant as pages (English page ) are called. For the page size, i.e. H. the number of list items transmitted per page, a maximum value is usually set. If the number of list elements contained in the response exceeds the maximum page size, several iterative method calls are required.

Event messages via MQTT

In the application programming interface, MQTT supplements the communication based on requests and responses via HTTP . With a request / response protocol such as HTTP, the application initiates communication with a request. With a publish / subscribe network protocol such as MQTT, however, applications are notified of events as they occur. Such an event can be, for example, a change in a sensory measured value. With an API based exclusively on HTTP, the applications would have to make regular inquiries as to whether a measured value has changed in order to gain real-time knowledge. In the application programming interface of an IoT platform, MQTT does not serve as an alternative, but as a supplement to HTTP. If requested, the HTTP API enables access to the time series of sensory measurement data recorded in the past. The MQTT API enables applications to be notified of current changes in the measured values ​​without delay. Depending on which devices are of interest for an application, it registers for one or more topics . The latter often correspond to the relative path of the URL in question:

…/devices/{deviceId}

Registration can also be limited to messages relating to a specific measured variable:

…/devices/{deviceId}/{tag}

After registration, no further request has to be made on the application side. Instead, the registered application receives a continuous sequence of individual messages that have the same data structure as the list elements of the recorded time series:

{
   "timestamp": "2019-10-23T07:07:32.939Z",
   "tag": "f1",
   "value": "83.32"
}

In addition to the transmission of sensory measured values, MQTT is also used to provide information about special events, such as exceeding limit values.

One of the reasons why MQTT has become a de facto standard as a communication protocol for the Internet of Things is because it is supported in every common programming language and the application programming interface and the protocol itself are simple and simple. Like HTTP, MQTT also provides a uniform interface for application programming with just a few methods. Thanks to the comprehensive support of cloud providers such as Amazon Web Services (AWS), Google and Microsoft , MQTT has now also developed into a leading IoT protocol for the acquisition of machine data.

Swagger or OpenAPI Specification

Device API in the Swagger UI

With Swagger is an open industry standard for the specification and documentation of a REST-like API. From version 3.0 the official name is OpenAPI Specification . An API specified with Swagger is documented in the Swagger User Interface ( Swagger UI ). The right figure shows the Swagger UI using the example of a device API. The addresses of the resources are not listed in full, but only the last part of the URL, which is called the relative path. The front part of the address - consisting of domain, port and base path - varies depending on the server on which the API is installed. Almost every IoT platform with an open, i. H. The API ( Open API ) documented in the World Wide Web now uses the Swagger Specification. The interactive Swagger UI , Swagger2Markup and ReDoc are provided as alternative open source tools for their documentation .

For the specification and documentation of event-driven architectures , the AsyncAPI specification was designed as a further open source tool based on the OpenAPI specification. It can be used to document application programming interfaces based on MQTT, but also other message-based communication protocols such as Advanced Message Queuing Protocol (AMQP) in the same way as in the Swagger UI. The data models ( schemas ) transmitted in the messages are often identical to those in the requests and responses of the associated REST API. They can be taken over directly from the OpenAPI specification in the AsyncAPI specification. The URLs are replaced by topics and the HTTP methods are replaced by the PUBLISH (PUP) and SUBSCRIBE (SUB) methods.

Individual characteristics

Different IoT platforms differ essentially in the range of devices supported in the IoT Hub, the design of the digital images of things in the API and their openness.

Platform openness

The API is not documented on the World Wide Web for all IoT platforms. Market and technology research companies such as Gartner or ISG publish regular market studies and provider comparisons for the industrially relevant IoT platforms. For some of the platforms listed in it, a Google search for a documented API has not yet returned any results.

An Open API increases the variety of applications offered for a platform and thus increases the attractiveness of the platform itself. However, once an application programming interface is public, incompatible changes lead to a loss of trust. For these reasons, many providers initially only make their platform's API available to a small group of development partners and only publish it when it has proven itself in practice. Since 2015, the first application programming interfaces for the IoT platforms of leading cloud providers and some large industrial groups have been published on the World Wide Web. They are all characterized by generically designed, abstract resources that do not define specific areas of application.

Platforms with a generically designed API

Digital image of things in a generically designed API

Due to the uniform interface of a REST-like API, the individual design options of the individual platform providers remain on the data model, i.e. H. limited to resource design. The simplest imaginable resource design leaves it with the simple mapping of the connected devices. This is in the Azure IoT platform from Microsoft the case, but any device ( device ), a digital still twin ( twin is assigned). The difference between the two resource types is that the digital twin of the devices is extended by a generic data structure for any description of the device properties.

The IoT platforms leading cloud providers and some large industrial groups characterizes a completely generic API designed to create, read, modify and delete any things ( things ), which optionally one or more devices ( devices ) are assigned. The following five interfaces are provided in the Leonardo IoT platform from SAP and the IoT Suite from Bosch :

• GET ... / things / to request a list of all entities
• GET ... / things / {id} to request a specific entity
• PUT ... / things / {id} to change a specific entity
• DELETE ... / things / {id} to delete a specific entity
• POST ... / things / to create a new entity

Other IoT platforms have slightly different interfaces. In Mindsphere from Siemens , the term assets is used instead of things . In Predix from General Electric (GE), assets are also mapped in the API, although the term does not appear in the URL of the resources. Instead, any lists of resources ( collections ) can be instantiated in the completely generic API that correspond to the technical objects ( domain objects ) of the respective subject area:

• GET / v1 to request a list of all collections
• POST / v1 / {collection} to create a specific object within a collection
• GET v1 / {collection} / {id} to request a specific object within a collection

In the Watson IoT platform from IBM and the AWS IoT platform , which belongs to a subsidiary of Amazon , things are categorized by assigning them to different thing types :

• GET / thing / types / {thingTypeId} / things / {thingId}
• PUT / thing / types / {thingTypeId} / things / {thingId}
• DELETE / thing / types / {thingTypeId} / things / {thingId}
• POST / thing / types / {thingTypeId} / things

Thing types can in turn be created and deleted generically, so that no specific areas of application are specified or excluded.

Every IoT application that was developed against a generically designed API can - as long as it does not use platform-specific cloud services - be migrated from one to the other IoT platform without major effort.

IIoT platforms

The term Industrial Internet of Things (IIoT) is often used for the industrial application of the Internet of Things and, linked to this, is sometimes referred to as IIoT platforms . IIoT contains a conceptual reference to the Industrial Internet , the US counterpart to German Industry 4.0 . That is coordinated and funded by the Industrial Internet Consortium, which not only includes international companies, but also research institutes and public institutions.

The application scenarios for IIoT platforms relate primarily to the area of ​​industrial production. GE explicitly describes its own Predix platform as a platform for the industrial Internet . Nevertheless, the providers of all IoT platforms with a generic API see use cases in the industrial environment, which promises the greatest market and sales potential for IoT platforms in the coming years. Because every generic API is basically open to application, the control and communication protocols supported by the IoT Hub largely determine the extent to which corresponding IoT platforms can be used in the industrial and manufacturing environment. Most production companies have a heterogeneous machine park, whose systems and machines are equipped with controls from various manufacturers and different years of construction. In the past, these various types of machine and system controls were read out as part of machine and process data acquisition, which later became an integral part of every Manufacturing Execution System (MES).

Discrete manufacturing platforms

For a long time, the prevailing view was that IoT platforms will complement the MES, but not replace it. Because the applications of the IoT platforms dominating the market do not cover the functional scope of an MES. In theory, completely generic data models allow an unlimited range of applications, but do not guarantee their semantic interoperability with one another and with the third-party systems customary in the manufacturing environment. Applications from the field of machine learning do not require any semantics, because they are independently able to identify recurring patterns as semantically assessable entities in the recorded time series. For example, the recurring patterns within the recorded process parameters before a technical malfunction can be used to forecast impending downtimes without knowing the physical meaning of the process parameters concerned. The predictive maintenance (English Predictive Maintenance ) of equipment and machinery on the basis of such projected downtime is therefore the application scenario for IIoT platforms, which is cited most often. However, the situation is different for tasks that require an algorithmic solution taking into account numerous technically justified framework conditions. Application developers need to be able to semantically evaluate data in order to manipulate it algorithmically, i. H. to be linked in a logical context. Both the default values ​​from the ERP system and the data from the recording systems are relevant for the detailed planning of production orders and the control of production. In order to provide a uniform, semantically assessable data basis on the application level, binding data models are required that are specified in the application programming interface. Concrete data models must necessarily be assigned to a specific area of ​​application ( domain specific ); However, a resource-oriented architecture allows an API to be designed as largely open to the application as possible within its application area, so that there is sufficient scope for the development of innovative and novel applications.

Digital image of the production in the API

In order to expand the range of applications of IIoT platforms in the manufacturing environment, FORCE Bridge API was published in 2018 as an Open API for Smart Manufacturing. The Swagger Specification was published under the Creative Commons Attribution-NoDerivs 3.0 Unported License , so that individual or all interfaces of the API can be implemented in any IoT platform. The API replaces the abstract things or the generic collections in Predix with concrete objects of production. These include the jobs (English Workplaces ), which may be machines or manual workstations, tools (English tools ) and the production staff (eng. Staff Members ). Manufacturing Solution ( Folders ) to include necessary for the production of a certain product documents (English Documents ) such as NC programs or assembly instructions. In the API and virtual objects such as are further production orders (English Production Orders ) including their individual operations (English Operations shown). Microsoft provides universities and educational institutions with a virtual factory with the API under discounted conditions in the Azure Cloud. Parts of the FORCE Bridge API are implemented in it, but the interfaces required for production control are missing.

Platforms for the oil and gas industry

The oil and gas industry not only sees a growing market for IIoT platforms, their use also holds the prospect of reducing the environmental impact by increasing efficiency and reducing CO ₂ emissions and safety risks. Above all, cloud providers with integrated services from the field of machine learning and artificial intelligence (AI) - although most of them do not come from the industrial sector - see the oil and gas industry as an area of ​​application for their IoT platforms. So should Cognitive Systems monitor all the information Bohrsensors in real time and compare with previous Bohrberichten and geological data to impending faults and failures to detect in advance.

IoT platforms specially developed for the oil and gas industry are characterized by the broad support of the various sensors and controls of drilling rigs and line systems, which they connect to the IoT hub and uniformly map in the API. The IoT platform of the company Cognite, founded in 2016, has an Open API and also provides a software development kit (SDK) for JavaScript and Python . The generically designed API is comparatively lean and clearly documented. For the users of the platform, the Open API has the advantage of being able to choose different providers of AI services regardless of the manufacturer and, if necessary, to be able to develop their own applications.

Platforms for the electronics industry

The surface mounting (English surface-mounting technology , short: SMT) of SMD components on circuit boards is automated to a high degree. An SMT line consists of several stations, which are usually obtained from different manufacturers. This includes a solder paste printer, SMD pick -and -place machine , SMD oven and several inspection and repair stations. In order to transfer the circuit boards themselves and the associated product data as well as information on machine settings and process feedback between the connected stations (horizontal integration), standards such as the SEMI SMT Equipment Link Standards (SEMI SMT-ELS), the IPC-SMEMA 9851 standard and the newer IPC-HERMES-9852 standard . With all these standards, communication between the individual stations of an SMT line takes place synchronously using the Transmission Control Protocol (TCP).

In order to connect SMT lines to an IoT platform (vertical integration), Connected Factory Exchange (CFX) was officially published by the IPC in 2019 . On the basis of AMQP , IPC CFX allows not only the asynchronous exchange of messages but also communication based on requests and responses. The CFX Messaging Library, an SDK developed for the Microsoft .NET software platform, has been available as open source since November 2017 . In principle, IPC CFX can be used not only to connect SMT lines to an IoT platform, but also as an application programming interface. The applications developed in this way for the SMT line could then not be executed on a platform that conforms to the usual IoT standards. This is at best practicable for applications that are specifically designed for the SMT line and without taking into account the rest, i.e. H. upstream and downstream workplaces are designed.

While the use of IoT platforms in most industrial areas is aimed at predictive maintenance of systems and machines, the electronics industry also focuses on predictive and proactive quality assurance. Thanks to the automatic optical inspection (AOI) at various stations on an SMT line, poorly processed parts are recognized immediately and are not even fed into the subsequent work step ( process interlock ). Instead, they are either corrected at a repair station and then reassigned to the inspection station or - if a correction is not possible - removed from the line as rejects. Machine learning methods make it possible to link the mass data generated by the AOI with other process parameters and to analyze recurring deviation patterns that indicate imminent quality defects in advance. The aim is to increase the proportion of circuit boards that are free of defects after the first production run without any repair steps, the so-called First Pass Yield (FPY), to 100 percent.

Platforms for building and home automation (Smart Home)

In contrast to the Industrial Internet of Things, the IoT market in the field of building automation (English Home Automation ) is by no means exclusively business-to-business (B2B), but especially in the field of smart living (English Smart Home ) primarily as business-to -Classify consumer (B2C). This can be seen, among other things, from the fact that there are a larger number of providers and no IoT platform without an openly documented API or SDK exists. A comprehensive overview can be found at ProgrammableWeb , where various IoT platforms for home automation and 69 application programming interfaces are presented, including a reference to their online documentation.

Advantages and disadvantages

The main advantage of IoT platforms is that they have created de facto standards that allow a wide range of software developers to develop applications for the Internet of Things. The implicit architecture concept of separating acquisition systems and the applications operating on them by an API usually leads to a reduction in side effects and susceptibility to errors and improves the maintainability of the source code compared to monolithic systems. The users of IoT platforms with an Open API have the advantage of being able to select each individual application regardless of the manufacturer according to the individual requirements. The more open an IoT platform, the lower the transaction costs and investment risks associated with its introduction . Because third-party providers can also access an Open API, open IoT platforms favor a broader range of providers and the development of innovative new applications.

The disadvantage of IoT platforms is that they can potentially have more security gaps compared to monolithic systems. Whether open application programming interfaces per se imply a higher risk is a much discussed question. On the one hand, they are easier to attack, on the other hand, the security risks are well known, so that potential security gaps can be closed more quickly. A decisive criterion is whether the platform is operated in a private network that is closed from the outside or in the cloud (see legal questions on cloud computing ). Regardless of this, every mobile application harbors the risk of unrecognized data being passed on to unauthorized third parties via the radio network. The unwanted forwarding of data can also take place after the mobile terminal has been transported and then connected to another network connected to the Internet. If only process data is involved, the expected damage is less than in the case of secret development documents or personal data. Therefore, different interfaces require different access rights with more or less strict restrictions.

See also

• Internet of things
• Swagger

Web links

• Swagger tools
• ReDoc
• Swagger2Markup
• AsyncAPI

Individual evidence

1. ↑ MS Schmid: The competition between business web strategies of competing company networks in the IPTV market . Springer Gabler, 2010
2. ↑ A. Baums: Digital Platforms - DNA of Industry 4.0 , viewed on October 27, 2019.
3. ↑ M. Friedemann, TU Trapp, J. Stoldt, T. Langer, M. Putz: A framework for information-driven manufacturing . Procedia CIRP 57 (2016), pp. 38-43, viewed on October 28, 2019.
4. ↑ Darrel Miller on GitHub: Supporting multiple transfer protocols with OpenAPI # 777 . Comment from 03 Dec 2016
5. ^ RT Fielding: Architectural Styles and the Design of Network-based Software Architectures . Diss. (2000)
6. ↑ Design News: Edge Devices Leverage MQTT for IIoT , September 4, 2019, viewed October 31, 2019.
7. ↑ SMARTBEAR: The State of API 2019 Report , viewed October 31, 2019.
8. ↑ The OpenAPI Initiative (OAI). Website .
9. ↑ Async API. Website .
10. ↑ Gartner Inc .: Industrial IoT Platforms Market , viewed October 30, 2019.
11. ↑ Information Services Group (ISG): New ISG provider study on the "Internet of Things" (IoT) , viewed on October 30, 2019.
12. ↑ Microsoft Azure IoT API Reference: Get Twin , viewed October 30, 2019.
13. ↑ SAP Leonardo API Reference: Things , viewed October 30, 2019.
14. ↑ Bosch IoT Suite API Reference: Bosch IoT Things HTTP API V2 , viewed October 31, 2019.
15. ↑ Siemens Mindsphere API Reference: Asset Management Service V 3.12.0 , viewed October 31, 2019.
16. ↑ GE Predix: API Documentation - Asset , viewed October 31, 2019.
17. ↑ AWS IoT API Reference: List Thing Types , viewed October 31, 2019.
18. ↑ Watson IoT API Reference: IBM Watson IoT Platform HTTP REST API , viewed October 31, 2019.
19. ^ Industrial Internet Consortium website , viewed October 30, 2019.
20. ↑ S. Luber, N. Litzel: What is the Industrial Internet of Things (IIoT)? , Bigdata Insider, October 20, 2017, viewed October 30, 2019.
21. ↑ GE: Predix - Your Platform for the Industrial Internet (PDF), viewed on October 30, 2019.
22. ↑ N. Hunke, Z. Yusuf, M. Rüßmann, F. Schmieg, A. Bhatia and N. Kalra: Winning in IoT: It's All About the Business Processes , viewed on October 31, 2019.
23. ^ C. Gupta: What Does IIoT Mean for MES? , Automation World, January 8, 2018, viewed October 31, 2019.
24. ^ G. Giles: What's Really New About IIoT? , Automation World, February 6, 2017, viewed October 31, 2019.
25. ↑ FORCE Bridge API: Swagger Specification as ReDoc , viewed on October 31, 2019. A complete Swagger Specification of the FORCE Bridge API (Version 2) that can be generated without errors using the Swagger Codegen can be found here under Online Plus on the Springer website.
26. ↑ Website of the virtual learning factory , viewed on October 31, 2019.
27. ↑ API Reference of the Virtual Learning Factory: Swagger Specification , viewed October 31, 2019.
28. ↑ Prakash Chakravarthi: 5 Ways IIoT Will Revolutionize the Oil and Gas Industry , IoT for all, July 30, 2018, accessed November 2, 2019.
29. ↑ IBM Whitepaper: Exploring the power of cognitive IoT (PDF), 2016, accessed November 2, 2019.
30. ↑ Cognite API (v1): Swagger Specification as ReDoc , accessed on November 2, 2019.
31. ↑ SEMI: SEMI SMT-ELS: SMT Equipment Link Standards , accessed on November 16, 2019.
32. ↑ IPC: The Hermes Standard IPC-HERMES-9852 , accessed on November 16, 2019. Download from https://www.the-hermes-standard.info/download/ .
33. ↑ IPC: The IPC publishes the guideline IPC-2591, Connected Factory Exchange (CFX) , accessed on November 16, 2019.
34. ↑ IPC: IPC-2591 , accessed November 16, 2019.
35. ↑ IPC: The new software toolkit CFX Messaging Library accelerates the implementation of Connected Factory Exchange , accessed on November 16, 2019.
36. ↑ Github: IPC Connected Factory Exchange (CFX) on Github , accessed November 16, 2019. Documentation on Getting Started with the SDK
37. ↑ ProgrammableWeb website: Category: Home Automation , accessed November 3, 2019.
38. ^ A. Sinsel, C. Bangert, J. Stoldt, T. Büttner: Economic evaluation of the smart factory . ZWF 112 (2017) 9, pp. 602-606.
39. ↑ IIoT World: An overview of the IoT Security Market Report 2017-2022 , accessed on November 2 of 2019.
40. ↑ G. Levin: TOP 7 REST API Security Threats . REST CASE, January 9, 2019, accessed November 2, 2019.
41. ^ G. Levin: State of API Security . REST CASE, October 25, 2019, accessed November 2, 2019.