FUTURE PROOFING AND PROTOTYPING AN INTERNET OF THINGS

NETWORK

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of the filing date of U.S. Patent Application No. 15/638,942, filed June 30, 2017, which claims the benefit of the filing date of U.S. Provisional Patent Application No. 62/379,313 and 62/379,339, filed August 25, 2016, all of which are incorporated herein by reference.

TECHNICAL FIELD

[0002] The present techniques relate generally to Internet of Things (loT) devices. More specifically, the present techniques relate to the field of loT data propagation and analysis.

BACKGROUND

[0003] A current view of the Internet is as a connection of clients, such as personal computers, tablets, smart phones, servers, digital photo-frames, and many other types of devices to publicly-accessible data-centers hosted in server farms. However, this picture represents a small portion of the overall usage of the globally- connected network. A very large number of connected resources currently exist, but are not publicly accessible. Examples include corporate networks, private

organizational control and monitoring networks spanning the globe, and peer-to-peer relays designed for anonymity.

[0004] It has been estimated that the Internet of Things (loT) may bring a multifold increase in Internet connectivity in just a few years. For organizations, loT devices may provide opportunities for monitoring, tracking, or controlling other devices and items, including further loT devices, other home and industrial devices, items in manufacturing and food production chains, and the like. Further, the emergence of loT networks has served as a catalyst for profound change in the evolution of the Internet. In the future, the Internet may evolve from an infrastructure that is oriented toward human utility, to an infrastructure where humans are minority actors in an Internet of increasing numbers of interconnected devices. Accordingly, the Internet may become a communications system for devices, and networks of devices, to not only communicate with data centers, but with each other. In the loT, functional networks may be constructed to perform specific tasks, and then deconstructed once the task is completed. Challenges exist in enabling reliable, secure, and identifiable devices to form networks for specific tasks such as these, and various other types of tasks as may be implemented in the loT.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Fig. 1 is a drawing of an example Internet of Things (loT) system;

[0006] Fig. 2 is a drawing of an example loT system for a mesh network of loT devices;

[0007] Fig. 3 is diagram of an example loT system for rapid prototyping;

[0008] Fig. 4 is a block flow diagram of an example method for rapid prototyping in an loT system;

[0009] Fig. 5 is a block flow diagram of an example method for rapid prototyping in an loT system;

[0010] Fig. 6 is block flow diagram an example method for future proofing an loT system;

[0011] Fig. 7 is diagram an example loT device for future proofing and rapid prototyping;

[0012] Fig. 8 is a block diagram of a non-transitory, machine readable medium including code to direct a processor to perform rapid prototyping in an loT system; and

[0013] Fig. 9 is a block diagram of a non-transitory, machine readable medium including code to direct a processor to future proof the loT system.

DESCRIPTION OF THE EMBODIMENTS

[0014] The Internet of things (loT) is a concept in which a large number of computing devices are interconnected to each other and to the Internet to provide functionality and data acquisition at very low levels. As used herein, an loT device may include a semi-autonomous device performing a function. The function may include sensing or control, among others. The loT device may communicate with other loT devices and a wider network, such as the Internet. Example networks of loT devices may include commercial and home automation devices, such as water distribution systems, electric power distribution systems, pipeline control systems, plant control systems, light switches, thermostats, locks, cameras, alarms, motion sensors, and the like. The loT devices may be accessible through remote

computers, servers, and other systems, to control systems or access data. Other loT devices may include loT gateways, which are used to couple loT devices to other loT devices, and to cloud applications. Cloud applications may include services, for example, such as data storage, process control, and the like.

[0015] The future growth of the Internet may include very large numbers of loT devices, each with their own respective standards and configurations. Accordingly, as described herein, a number of innovations for the future Internet address the need for all these layers to grow unhindered, to discover and make accessible connected resources, and to support the ability to hide and compartmentalize connected resources. Any number of network protocols and communications standards may be used, wherein each protocol and standard is designed to address specific objectives. Further, the protocols are part of the fabric supporting human accessible services that operate regardless of location, time or space. The innovations include service delivery and associated infrastructure, such as hardware and software. The services may be provided in accordance with the Quality of Service (QoS) terms specified in service level and service delivery agreements.

[0016] Future innovations in the loT may implicate new architectures that incorporate such innovations. Examples may rapidly prototype different potential configurations that can be future proofed by determining which configurations are efficient, cost-effective, and the like. Prototyping for an loT network involves generating workloads on an loT network that resemble real-world scenarios.

Further, prototyping includes capturing these workloads in end-to-end loT use case definitions and testing the use cases on an loT network. Workloads are collections of workflows, which are series of events that take place on an loT network. The end- to-end loT use case definitions are thus characterized by workflows that exercise a number of software events and interrupts of varying priorities and dependencies. However, attempting to test workflows with real-world events in a real-world loT network would be time consuming and expensive, thereby contributing to prototyping delays and rendering many potential prototype evaluations infeasible.

[0017] In current systems, prototyping may be carried out by evaluating characteristics of a small subset of real world clients and triggers that are not representative of real world workloads, which constitute multiple parallel triggers, thereby resulting in inaccurate and largely insufficient data points to carry out concept evaluations. Concept evaluations are methods for determining the feasibility of a new concept, such as a new gateway for an loT network.

[0018] An loT statistic characterization process that determines workload impact for current and estimated future workloads uses an loT rapid prototyping engine. The loT rapid prototyping engine enables the evaluation of statistic characteristics using accurate representations of real world client and triggers via simulated end point clients and external triggers. Further, embodiments of the claimed subject matter enable complex workflow and statistic characteristics analysis, thereby providing rapid prototyping capabilities.

[0019] Workloads are simulated incrementally from simple representations to scaled-up complex inputs on modelled edge gateway architectures, with the resulting statistic characteristics documented for offline evaluation. The outlined

embodiments describe the evaluation of simulating the workflows on the modelled gateways and the resulting statistic characteristics. Statistic characterization represents an evaluation on a specific statistic that is to be tracked during simulation. For example, the RAM capacity, CPU use, buffer sizes, how many full buffers, round-trip latency, hop-to-hop latency, are some example statistics that may be tracked for the simulation of the prototype on a simulated loT network.

[0020] Fig. 1 is an example Internet of Things (loT) system 100. The system 100 includes a cloud 102, servers 104, multiple loT devices 106, 108, 1 10, 1 12, 1 14, 1 16, 1 18, a group 120 of loT devices, and a gateway 122. The cloud 102 may represent the Internet, or may be a local area network (LAN) or a wide area network (WAN), such as a proprietary network for a company. The server 104, various loT devices 106, 108, 1 10, 1 12, 1 14, 1 16, 1 18, and gateway 122, may be real, virtual, or simulated. Indeed, the representations in Fig. 1 may be real or simulated with respect to their depiction and in evaluation, including in any hybrid operation of the live real loT components with simulated or emulated components.

[0021] The network topology may include various types of loT networks, such as a mesh network via Bluetooth® low energy (BLE) links. Other types of loT networks may include a wireless local area network (WLAN) network to communicate with loT devices through IEEE 802.1 1 (Wi-Fi®) links, a cellular network to communicate with loT devices through an LTE/LTE-A (4G) or 5G cellular network, and a low-power, wide area (LPWA) network. A LPWA network may be compatible with the long range wide area network (LoRaWAN™) specification promulgated by the LoRa alliance. The network topology or loT network(s) may include IPv6 over Low Power Wide-Area Networks (LPWAN) network compatible with a specification promulgated by the Internet Engineering Task Force (IETF). Further, the respective loT networks may communicate with an outside network provider (e.g., a tier 2 or tier 3 provider) via a variety of communications links, such as an LTE cellular link, an LPWA link, or a link based on the IEEE 802.15.4 standard, such as Zigbee®, and so on. The respective loT networks may also operate by network and internet application protocols such as Constrained Application Protocol (CoAP). The respective loT networks may also be integrated with coordinator devices that provide a chain of links that forms cluster tree of linked devices and networks.

[0022] Although wireless networks and wired networks are described, such as LPWA links, optical links, and the like, it may be noted that any type of network may be used to couple the devices to each other or to a gateway 122. A network or assembled group of devices may have both wired and wireless connections, and may use both simultaneously between nodes, peers, and gateway devices. Further the network or assembled group of devices may use wired networks, wireless networks, or both, to communicate with the cloud, and any higher performance computing devices that may be participating to deliver services or support to what is disclosed herein. Thus, any loT link 1 08 or loT network 1 1 2 may use a wired or wireless connection. Further, loT devices may be in direct communications with other devices in the cloud 102 without the use of a gateway 122. The backbone links 108 may include various wired or wireless technologies, including optical networks and, again, may be part of a LAN, a WAN, or the Internet. Additionally, such communication links facilitate optical signal paths among both loT devices with the cloud 102 and the gateway(s) 1 1 0, including the use of MUXing/deMUXing components that facilitate interconnection of the various devices.

[0023] As can be seen from Fig. 1 , a large number of loT devices may be communicating through the cloud 102. These loT devices may be grouped in combinations to perform a common function, such as loT devices for remote weather stations 106, local information terminals 1 08, alarm systems 1 10, automated teller machines 1 12, alarm panels 1 14, or moving vehicles, such as emergency vehicles 1 16 or drones 1 18, among many others. Each of these loT devices may be in communication with other loT devices, with servers 104, or both. The loT devices 106, 108, 1 10, 1 12, 1 14, 1 1 6, 1 18 may include any number of different types of sensors, computing devices, and the like. The servers 104 may be one or more computing devices that provides a service for, or communicates in some other capacity with one or more loT devices 106, 1 08, 1 10, 1 1 2, 1 14, 1 16, 1 18 and group 120. Moreover, in profiling and diagnostics, the servers 104 and the various loT devices 106, 108, 1 10, 1 12, 1 14, 1 16, 1 1 8 may be real, virtual, or simulated.

[0024] In one example, the group 120 is a traffic control group that includes loT devices along streets in a city. These loT devices may include stoplights, traffic flow monitors, cameras, weather sensors, and the like. The loT devices in the traffic control group may use another device, such as the gateway 1 22 to communicate with the cloud 102. The traffic control group, or other subgroups, may be in communication with the cloud 102 through wireless links 124, such as LPWA links, and the like. Further, a wired or wireless sub-network 1 26 may allow the loT devices to communicate with each other, such as through a local area network, wireless local area network, and the like. In some examples, the sub-network 126 may couple one or more of the loT devices to the gateway 1 22 using a wired network. Additionally, the loT devices of the group 1 20 may also use one or more servers (not shown) operationally disposed along the gateway 122, or between the group 120 and the gateway 122, to facilitate communication of the group 120 with the cloud 102 or with the gateway 122. For example, the one or more servers may operate as an intermediate network node to support a local edge cloud or fog implementation among a local area network.

[0025] This may allow different loT devices to request or provide information to other devices autonomously. For example, the traffic group 120 may request a current weather forecast from a group of remote weather stations 106, which may provide the forecast without human intervention. Further, an emergency vehicle 1 16 may be alerted by an automated teller machine 1 12 that a burglary is in progress. As the emergency vehicle 1 16 proceeds towards the automated teller machine 1 12, it may access the traffic group 120 to request clearance to the location, for example, by lights turning red to block cross traffic at an intersection in sufficient time for the emergency vehicle 1 16 to have unimpeded access to the intersection.

[0026] Clusters of loT devices, such as the remote weather stations 106 or the traffic control group, may be equipped to communicate with other loT devices as well as with the cloud 102. Moreover, in profiling and diagnostics, the weather stations 106 and the various loT devices 108, 1 1 0, 1 12, 1 14, 1 16, 1 18 may be real, virtual, or simulated. This may allow the loT devices to form an ad-hoc network or virtual network between the devices, allowing them to function as a single device, which may be termed a fog device. The fog device is discussed further with respect to Fig. 2.

[0027] Fig. 2 is an example loT system 200 for a mesh network of loT devices (fog device 202). In embodiments, the fog device 202 operates at the edge of the cloud 102. As used herein, the fog device 202 is a cluster of devices that may be grouped to perform a specific function, such as traffic control, weather control, plant control, home monitoring, and the like.

[0028] Although the fog device 202 is shown as a mesh network in this example, using gateways, such as gateway 122 to communicate with devices in the cloud 102, the devices do not have to be part of a mesh network, or even proximate to each other to form a fog device. Thus, the devices do not have to be in direct radio or network communications with each other, or proximate to each other, but may form an ad hoc group based on function. The formation of the fog device 202 may be as simple as sharing naming, type, and identification information, for example, group identity credentials, between the different devices forming the fog device. This may allow any device to act as a representative of the fog device 202, with providing identity specific to the device. As an example, although the fog device 202 is this example is shown as being made up of devices in a single location, fog devices can include devices in multiple locations, formed to provide specific services. For example, the fog device 202 may include remote weather stations located in the cloud 102. Further, a server 104 located in a data center may be included in the fog device 1 02 for data analysis, and other services. Moreover, in profiling and diagnostics, the cloud 102, server 104, fog device 202 and the various remote weather stations, may be real, virtual, or simulated.

[0029] In another example, the fog device 202 is a group of loT devices for regulating traffic at an intersection. The fog device 202 may be established in accordance with specifications released by the OpenFog Consortium (OFC), among others. These specifications allow the formation of a hierarchy of computing elements between the gateways 122 coupling the fog device 202 to the cloud 102 and endpoint devices, such as traffic lights 204 and data aggregators 206 in this example. The fog device 202 can leverage the combined processing and network resources that the collective of loT devices provides.

[0030] Traffic flow through the intersection may be controlled by a plurality of traffic lights 204 (e.g., three traffic lights 204). Analysis of the traffic flow and control schemes for traffic may be implemented by aggregators 206 that are in

communication with the traffic lights 204 and each other through a mesh network. Data may be uploaded to the cloud 1 02, and commands may be received from the cloud 102, through gateways 122 that are in communication with the traffic lights 204 and the aggregators 206 through the mesh network. In some aspects, the fog device 202 can include temporary loT devices. In other words, not all of the loT devices in the mesh network may be permanent members of the fog device 202. In the example loT system 200, three transient loT devices have joined the fog device 202, a first vehicle 212, a second vehicle 214, and a pedestrian 21 6. In these cases, the loT device may be built into the vehicles 212 and 214, or may be an App on a cell phone carried by the pedestrian 21 6. Moreover, in profiling and diagnostics, the cloud 102, server 104, gateways 122, fog device 202, traffic lights 204, aggregators 206, vehicles 212, 214, pedestrians 214, and the like, may be real, virtual, or simulated.

[0031] The fog device 202 may be considered to be an interconnected network wherein a number of loT devices are in communications with each other, for example, by the communication links 208 and 210, through the cloud 102 via a network communications link, or through a gateway 1 22. For devices proximate to one another, the network may be established using the open interconnect consortium (OIC) standard specification 1 .0 released by the Open Connectivity Foundation™ (OCF) on December 23, 2015. This standard allows devices to discover each other and establish communications for interconnects. Other interconnection protocols may also be used, including, for example, the optimized link state routing (OLSR) Protocol, or the better approach to mobile ad-hoc networking (B.A.T.M.A.N.), among many others. Any number of communications links may be used in the fog device 202. Shorter-range links 208, for example, compatible with IEEE 802.1 5.4 may provide local communications between loT devices that are proximate to the intersection. Longer-range links 210, for example, compatible with LPWA standards, may provide communications between the loT devices and the gateways 1 22. To simplify the diagram, not every communications link 208 or 21 0 is labeled with a reference number. Further, not every device that participates in the fog device 202 needs to be located proximate to the other devices or in direct radio communications. For example, the fog device 202 may incorporate a weather station located on a different network.

[0032] One or more of the communications links 208 and 210 may be replaced with a wired connection between two devices. The network forming the fog device 202 does not have to be a mesh network, but may be a standard network in which each device is coupled to other devices through a wired or wireless connection to the gateway 122.

[0033] In some aspects, communications from any loT device 204, 206, 212, 214, 216 may be passed along the most convenient path between any of the loT devices 204, 206, 212, 214, 216 to reach the gateways 122, for example, the path having the fewest number of intermediate hops, or the highest bandwidth, among others. In mesh networks, the number of interconnections provides substantial redundancy, allowing communications to be maintained, even with the loss of a number of loT devices.

[0034] The fog device 202 of the devices may be presented to clients in the cloud 102, such as the server 104, as a single device located at the edge of the cloud 102. In this example, the control communications to specific resources in the fog device 202 may occur without identifying any specific loT device within the fog device 202. Accordingly, if an loT device fails, other loT devices may be able to discover and control a resource. For example, the traffic lights 204 may be wired so as to allow any one of the traffic lights 204 to control lights for the other traffic lights 204.

[0035] In some examples, the loT devices 204, 206, 212, 214, 216 may be configured using an imperative programming style, e.g., with each loT device having a specific function and specific communication partners. However, in some embodiments, the loT devices 204, 206, 212, 214, 216 forming the fog device 202 may be configured in a declarative programming style, allowing the loT devices 204, 206, 212, 214, 216 to reconfigure their operations and communications, such as to determine needed resources in response to conditions, queries, device failures, and the like. For example, as transient loT devices, such as the vehicles 212, 214 and the pedestrian 216, join the fog device 202, the fog device 202 may modify the operation of the fog device 202. In one example, a temporary group including the vehicles 21 2, 214 and the pedestrian 216 may be formed. The temporary group may modify the operation of the traffic lights 204 so the pedestrian 216 has sufficient time to cross the intersection. To address safety concerns, if one or both of the vehicles 212, 214 are autonomous, the temporary group may modify the operation of any autonomous vehicles to slow down prior to arriving at the intersection. Further, as the transient devices 212, 214, 216, leave the vicinity of the intersection, the fog device 202 may reconfigure itself to eliminate the loT devices 212, 214, 21 6 from the network. As other transient loT devices approach the intersection, the fog device 202 may reconfigure itself to include those devices, and so on.

[0036] Embodiments of a traffic system in the loT, such as the loT system 200, may have other types of configurations as well. For example, the fog device 202 may include the traffic lights 204 for a number of intersections, such as along a street, along with all of the transient loT devices along the street. The fog device 202 may then divide itself into functional units, such as the traffic lights 204 and other loT devices proximate to a single intersection. This type of combination may enable the formation of larger loT constructs in the fog device 202. Hence, if an emergency vehicle joins the fog device 202, an emergency construct, or virtual device, may be created that includes all of the traffic lights 204 for the street, allowing control of the traffic flow patterns for the entire street. The emergency construct may instruct the traffic lights 204 along the street to stay red for opposing traffic, and green for the emergency vehicle, expediting the passage of the emergency vehicle.

[0037] loT systems such as, the loT system 200, may be complex and hence, may provide a number of challenges in their implementations. For example, loT systems may include numerous types of devices, communication links, protocols, and the like, which may be configured in a number of different potential

implementations. Thus, determining what configurations are available, and which of those configurations accommodate the loT system requirements may be

challenging. Accordingly, certain embodiments provide for a system to perform simulations of potential loT systems (prototypes), on the loT system itself.

[0038] For instance, simulation code may be stored and executed on the fog device 202, or on other devices in an loT system, such as the data aggregators 206 of the fog device 202. The simulation may perform various simulated configurations of an loT system. Simulations may include different workloads on the existing loT architecture giving resulting statistic characteristics. In some examples, the simulation system disposed in the loT system may iterate through simulated incremental values of workload values, architecture or gateway values, and observed statistic characteristics values. In particular examples, the simulations may provide for reconfiguring a fog device 202, for example, by modelling a change in which loT devices are used to provide particular functions.

[0039] Moreover, an loT simulation system may be installed and executed on an existing fog device 202, or on other devices in an loT system. The installation of the loT simulation system may allow for the creation of a virtual loT device that includes both virtual and real loT devices. The virtual and real loT devices thus represent a hybrid system architecture, where simulation of a proposed future architecture and a live architecture run at the same time on the same virtual machine. The virtual loT device may allow for testing different configurations of loT devices, for example, before adding additional loT devices to a fog device 202 or reconfiguring

communications in a fog device 202. The test results may represent functionality, stability, and the like, as the configuration changes. Moreover, in profiling and diagnostics, the cloud 102, server 104, gateways 122, fog device 202, traffic lights 204, aggregators 206, and the like, may be real, virtual, or simulated. Furthermore, components shown in Fig. 2, such as the gateway, fog device, and various sensors or servers, may be real, virtual, or simulated. Indeed, the representations in Fig. 2 may be real or simulated with respect to their depiction and in evaluation, including in any hybrid operation of the live real loT components with simulated or emulated

components.

[0040] Indeed, the simulations for evaluating evaluating or detecting anomalies may run and operate in an environment where both live loT systems and the

simulation/emulation are running together to consider, for example, an expansion of an loT system by testing the proposed architecture. Thus, embodiments may include a hybrid of live and simulated/emulated systems. This hybrid set-up may accommodate opportunity to test, for example, system capacity and fault recovery scenarios.

[0041] Fig. 3 is an example loT system 300 for rapid prototyping. The system 300 includes a control user interface (Ul) 302 (installed on a computing device 304), an automation framework 306 and end point simulators 308 (also installed on computing device 304), real and simulated gateways 31 0 (simulated gateways installed on computing device 304), and the cloud 312. Moreover, in profiling and diagnostics, the loT system 300, control Ul 302, computing device 304, automation framework 306, endpoint simulators 308, gateways 310, and the cloud 312 may be real, virtual, or simulated. [0042] The control Ul 302 may be used to create a simulated loT system on which to execute the workloads. The simulated loT network is defined using configuration parameters such as the number of sensors, sensor publish

frequencies, packet sizes, burstiness of the traffic profiles, quality of service (QoS) values of merge queueing telemetry transport (MQTT) based transmissions, are a few examples of parameters to define a simulated loT network. The control Ul 302 has the ability to dynamically modify runtime parameters, which gives the edge infrastructure the ability to accurately represent real world scenarios. Dynamically modifying runtime parameters means using the control Ul 302 to take an event generated by the end point simulators 308, and changing the sensed value.

Modifications can happen during run time execution of the simulated model. The control Ul 302 initiates monitoring daemons in each of the devices the control Ul 302 controls, e.g., the simulated sensors and sensor hubs, the gateways 31 0, and servers in the cloud 31 2. The monitoring daemons track the statistics used to characterize a prototype simulation. In one embodiment, monitoring daemons can be run on the cloud 312 to monitor the receipt of sensed values, the subsequent analysis, and actuation.

[0043] The end point simulators 308 generate events for the simulated workload based on models of the different types of events that occur. The type of event generated depends on what the components of the simulated loT network do. One example of an event is when any of the sensors transmits a measurement or other sensed value via Bluetooth to an aggregator. Another example event is the number of transient devices expected to join or leave the mesh network per unit of time. The end point simulators 308 include models for various types of communication protocols used by sensors in an loT network. The values may be determined randomly.

[0044] The automation framework 306 is used to perform the simulation of processing the workload in the simulated loT network. In one embodiment, the automation framework 306 inputs events generated by the end point simulators 308 to a simulated loT network. More specifically, the automation framework 306 issues control sequences to end point devices, real and simulated, via the control Ul 302. During a learning phase where the event models are built, the control sequences to the end points are issued for the purposes of learning the resultant statistic characteristics. During the run phase, the end point simulators 308 are controlled for the purpose of predicting expected statistic characteristics. The edge infrastructure provides API's for canned trigger scripts to interact. The set of API's exchange a standard set of timing information that allows the trigger scripts to identify

synchronous versus staggered starts. These scripts may be stored anywhere in the edge infrastructure, or even the cloud 312. However, storing the scripts closest to the edge is more efficient than at the gateways 310 and the cloud 312.

[0045] The real and simulated gateways 310 are used for different purposes. The real gateways are used to collect statistic characteristics information during the learning phase of the model building. The data is then used to build the simulated loT network, i.e., the simulation model, wherein gateways 310 and end points are simulated entities. The simulated gateways process the events generated by the end point simulators 308, and pass the sensor information to the cloud 312. Once the simulation is executed, the statistics tracked by the monitoring daemons are stored in an IOT database.

[0046] The loT database is an integrated database that stores workflow configuration parameters, results logging, and enables binary searches and pruning based on results from prior runs. Interactions with the database are controlled via the control Ul 302. This arrangement allows for the security and integrity of the stored data. Allowing the database values to only be controlled via the control Ul 302 allows for fewer entry points and a single point to protect against threats, such as malicious users, viruses, etc. Workflow configuration information, observed system performance, and the resulting statistic characteristics are stored in each tuple in the loT database. In this way, the loT database may enable the building of functions that extrapolate statistic characteristics and system performance for a range of incremental workload parameters, which may give the edge architecture the capability of being able to run thousands of permutations to identify the most optimal hardware or application what-if scenarios. Extrapolations often refer to linear models, but that may not be the case. The expected statistic characteristics could also be step functions as determined by the nature of the architecture of the simulated loT network. Additionally, the loT database may be stored anywhere in the edge infrastructure, but is more efficiently maintained and used if stored on the gateway 310 or another aggregation device.

[0047] In these ways, the system 300 may enable optimal statistic size loT deployments using an edge infrastructure with simulated end points (sensors), real and simulated aggregation devices (e.g., gateways 310, sensor hubs), the control Ul 302, automation framework 306, and the loT database. The loT database can reside anywhere in the edge infrastructure. However, placing the loT database on the gateway 310 results in faster lookups than if placed on other parts of the edge infrastructure. Moreover, in profiling and diagnostics, the loT system 300, control Ul 302, computing device 304, automation framework 306, endpoint simulators 308, gateways 310, and the cloud 312 may be real, virtual, or simulated.

[0048] Lastly, all of the devices depicted in the loT system 300 of Fig. 3 can represent physical devices that are existing and real. However, any of the devices depicted in the loT system 300 of Fig. 3 could be virtual or simulated. Indeed, the architectural elements disclosed herein such as loT objects, network entities, servers, gateways or other nodes can be either real, virtual, or simulated. There may be an interchangeability of real, virtual, and simulated with respect to the depictions and representations of loT system devices in the present specification and drawings. Moreover, the simulations for evaluating and detecting anomalies may run and operate in an environment where both live loT systems and the simulation/emulation are running together to consider, for example, an expansion of an loT system by testing the proposed architecture. Thus, embodiments may include a hybrid of live and simulated/emulated systems. This hybrid set-up may accommodate opportunity to test, for instance, system capacity and fault recovery scenarios. Moreover, the proposed expansion for an architecture may involve already-installed or existing devices outside of the loT system to which the loT system will incorporate or tie into, or can involve new loT devices to be installed, and so on.

[0049] Fig. 4 is an example method 400 for rapid prototyping in an loT system. The method 400 begins at block 402, and is performed by the automation framework 306. At block 404, workload characteristics are converted into end point simulation workloads (W, _...m ). Each workload is a simulated representation of an actual workload as would be represented in a real world deployment scenario, the aggregated load which represents the workflow in its entirety. At block 406, gateway hardware characteristics are converted into modeling elements (G, ... _n )- Each of the relevant components and their interactions are represented within the model thereby characterizing the behavior of the actual system during workflow executions. At block 408, the simulation is performed for each workload, and gateway modeling elements. The tracked statistics for the simulation are recorded in S,. At block 41 0, it is determined if simulations have been run for all workloads and gateway configurations. If there are more, the next simulation is run at block 408. If there are no more, the method 400 stops at block 412. Moreover, in profiling and diagnostics, the loT system, automation framework 306, endpoint simulation workloads, gateway modeling elements, and the like may be real, virtual, or simulated.

[0050] Fig. 5 is an example method 500 for rapid prototyping in an loT system. As stated previously, in profiling and diagnostics, the loT system, automation framework, endpoint simulation workloads, gateway modeling elements, and the like may be real, virtual, or simulated. This may enable future proofing of rapid prototypes by varying workflows and gateway configurations, for example. However, some variations in the workflows and gateway configurations, do not create a great deal of variation in the statistics resulting from the simulation. In such cases, embodiments of the claimed subject matter may automatically eliminate similar workflows or gateway configurations from the executed simulations. The method 500 is performed for each simulation. Additionally, the method 500 begins at block 502, and is performed by the automation framework 306. At block 504, a simulation result is identified. At block, 506, it is determined whether the statistic, S, exceeds a specified threshold of variation. If so, the method 500 flows to block 51 0, then returns to block 504 to identify the next simulation. However, if the statistic, S, does not exceed the specified threshold of variation, at block 508, the respective workflow and gateway entries are removed from the potential simulations. The method 500 ends at block 512.

[0051] Workflow iterations as described in the illustration in figure 5, identify a workload consisting of workflows (W _iw , iw=1 ...n) and Gateway characteristics (Gig, ig=1 ..n). Observed statistic characteristics (Si) are measured against the previous runs. An absence of a variation, which may be a configurable parameter, would eliminate further increments in the workflow suite for the rest of the workflow sequence therefore eliminating a series of workloads from the simulations.

[0052] loT applications are in their early years of development, which obscures the ability to perform accurate headroom analysis applications deployed in an loT network. In current systems, when attempts are made to perform headroom analysis, they are based on linear extrapolations of current usage, which results in inaccurate representations of the workings of the target loT network. [0053] The target loT network may also refer to the hardware architecture, such as the system deployment, the target gateway including CPU, memory, and storage specifications, and also to whether the gateway architecture is real, virtual, a hybrid of real and virtual, and so on. The target loT network thus provides a background against which the characteristics of an observed loT system are evaluated for a given gateway architecture. The "proposed solution" may be the contemplated or simulated observed characteristic(s), or potential response of a given architecture for a considered workload, and other features or representations, and so on.

[0054] Accordingly, future proofing loT architectures is now made possible by performing headroom analysis of simulations of target workflows executed on modelled gateways, as described with respect to Figs. 3-5. Target workflows may be approximations of the workload expected in future proofing scenarios.

Embodiments of the clamed subject matter can be extended to contexts, such as processing utilization, memory, storage, and l/O's, within edge sensor modules, sensor hubs, and on data servers within the cloud. In embodiments, an loT architecture characterization process evaluates a proposed architecture against the requirements of future workflows.

[0055] Future target workflows are simulated and extended on current and future simulated edge gateway models. Estimated metrics for the simulations are evaluated for optimal returns against pre-defined set of technical goals. The outlined embodiments describe the evaluation of the executed simulated future workflows on the modelled gateways and its lookup against quantified targeted technical solution characteristics by means of an integrated lookup table.

[0056] Furthermore, components such as the gateway and various sensors or servers, may be real, virtual, or simulated. Indeed, the representations described with respect to Fig. 5 may be real or simulated with respect to their depiction and in evaluation, including in any hybrid operation of the live real loT components with simulated or emulated components.

[0057] loT applications may be poised to integrate a growth of new and increasingly complex applications in the years to come. In order to accommodate this growth and prevent expensive overhauls of deployed loT architectures, headroom analysis of future deployment scenarios is useful. Headroom analysis is a way to identify how much capacity is remaining for a specific resource before a bottleneck occurs. Accordingly, embodiments of the claimed subject matter iterate through numerous workflow permutations with the ability to determine the

implications of potential future: changes to the workload, and upgrades to the gateway architecture of the loT network. Such an embodiment enables complex what-if analysis capabilities that help identify potential future infrastructure

bottlenecks and the impact on them from possible proposed upgrades, thereby providing insights that help determine the optimal target solution architecture that accommodates the workload and gateway architecture changes. In this way, embodiments of the claimed subject matter obviate potentially expensive overhauls of existing loT network infrastructure.

[0058] Fig. 6 is an example method 600 for future proofing an loT system. The method 600 determines a proposed future workload is compliant relative to the desired technical goals, and is performed by the automation framework 306. The method 600 begins at block 602. At block 604, the automation framework 306 helps define technical requirements based on target future workloads. At block 606, a simulation is executed for a given workflow and gateway configuration. At block 608, the automation framework evaluates the simulation, and determines the architecture and workflow characteristics against the modelled gateway architecture, and compares these architecture characteristics against the devices' desired technical architecture and workflow-level metrics by performing a lookup to the loT database. Each workflow permutation is exercised in this manner using an iteration generator until all target input workflows have been exhausted. All deviations outside of the target architecture parameters are flagged as non-compliant and marked for further evaluations. Furthermore, components such as the gateway and various sensors or servers, may be real, virtual, or simulated. Indeed, the representations described with respect to Fig. 5 may be real or simulated with respect to their depiction and in evaluation, including in any hybrid operation of the live real loT components with simulated or emulated components.

[0059] Fig. 7 is an example loT system 700 for future proofing and rapid prototyping. The loT system 700 may include any combinations of the components shown in the example. The components may be implemented as ICs, portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in the loT system 700, or as components otherwise incorporated within a chassis of a larger system. The block diagram of Fig. 7 is intended to show a high level view of components of the loT system 700. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

[0060] The loT system 700 may include a processor 702, which may be a microprocessor, a multi-core processor, a multithreaded processor, an ultra-low voltage processor, an embedded processor, or other known processing element. The processor 702 may be a part of a system on a chip (SoC) in which the processor 702 and other components are formed into a single integrated circuit, or a single package, such as the Edison™ or Galileo™ SoC boards from Intel. As an example, the processor 702 may include an Intel® Architecture Core™ based processor, such as a Quark™, an Atom™, an i3, an i5, an i7, or an MCU-class processor, or another such processor available from Intel® Corporation, Santa Clara, CA. However, any number other processors may be used, such as available from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, CA, a MlPS-based design from MIPS

Technologies, Inc. of Sunnyvale, CA, an ARM-based design licensed from ARM Holdings, Ltd. or customer thereof, or their licensees or adopters. The processors may include units such as an A5-A9 processor from Apple® Inc., a Snapdragon™ processor from Qualcomm® Technologies, Inc., or an OMAP™ processor from Texas Instruments, Inc.

[0061] The processor 702 may communicate with a system memory 704 over a bus 706. Any number of memory devices may be used to provide for a given amount of system memory. As examples, the memory can be random access memory (RAM) in accordance with a Joint Electron Devices Engineering Council (JEDEC) low power double data rate (LPDDR)-based design such as the current LPDDR2 standard according to JEDEC JESD 209-2E (published April 2009), or a next generation LPDDR standard, such as LPDDR3 or LPDDR4 that will offer extensions to LPDDR2 to increase bandwidth. In various implementations the individual memory devices may be of any number of different package types such as single die package (SDP), dual die package (DDP) or quad die package (Q1 7P). These devices, in some embodiments, may be directly soldered onto a motherboard to provide a lower profile statistic, while in other embodiments the devices are configured as one or more memory modules that in turn couple to the motherboard by a given connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., dual inline memory modules (DIMMs) of different varieties including but not limited to microDIMMs or MiniDIMMs. For example, a memory may be sized between 2GB and 16GB, and may be configured as a DDR3LM package or an LPDDR2 or LPDDR3 memory, which is soldered onto a motherboard via a ball grid array (BGA).

[0062] To provide for persistent storage of information such as data, applications, operating systems and so forth, a mass storage 708 may also couple to the processor 702 via the bus 706. To enable a thinner and lighter system design the mass storage 708 may be implemented via a solid state disk drive (SSDD). Other devices that may be used for the mass storage 708 include flash memory cards, such as SD cards, microSD cards, xD picture cards, and the like, and USB flash drives. In low power implementations, the mass storage 708 may be on-die memory or registers associated with the processor 702. However, in some examples, the mass storage 708 may be implemented using a micro hard disk drive (HDD).

Further, any number of new technologies may be used for the mass storage 708 in addition to, or instead of, the technologies described, such resistance change memories, phase change memories, holographic memories, or chemical memories, among others. For example, the loT system 700 may incorporate the 3D XPOINT memories from Intel® and Micron®.

[0063] The components may communicate over the bus 706. The bus 706 may include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extended (PCIx), PCI express (PCIe), or any number of other technologies. The bus 706 may be a proprietary bus, for example, used in a SoC based system. Other bus systems may be included, such as an I2C interface, an SPI interface, point to point interfaces, and a power bus, among others.

[0064] The bus 706 may couple the processor 702 to a mesh transceiver 710, for communications with other mesh devices 712. The mesh transceiver 71 0 may use any number of frequencies and protocols, such as 2.4 gigahertz (GHz) transmissions under the IEEE 802.15.4 standard, using the Bluetooth® low energy (BLE) standard, as defined by the Bluetooth® Special Interest Group, or the ZigBee® standard, among others. Any number of radios, configured for a particular wireless

communication protocol, may be used for the connections to the mesh devices 712. For example, a WLAN unit may be used to implement Wi-Fi™ communications in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 standard. In addition, wireless wide area communications, e.g., according to a cellular or other wireless wide area protocol, can occur via a WW AN unit.

[0065] The mesh transceiver 710 may communicate using multiple standards or radios for communications at different range. For example, the loT system 700 may communicate with close devices, e.g., within about 10 meters, using a local transceiver based on BLE, or another low power radio, to save power. More distant mesh devices 712, e.g., within about 10 meters, may be reached over ZigBee or other intermediate power radios. Both communications techniques may take place over a single radio at different power levels, or may take place over separate transceivers, for example, a local transceiver using BLE and a separate mesh transceiver using ZigBee. The mesh transceiver 710 may be incorporated into an MCU as an address directly accessible by the chip, such as in the Curie® units available from Intel.

[0066] An uplink transceiver 714 may be included to communicate with devices in the cloud 1 02. The uplink transceiver 714 may be LPWA transceiver that follows the IEEE 802.1 5.4, or IEEE 802.15.4g standards, among others. The loT system 700 may communicate over a wide area using LoRaWAN™ (Long Range Wide Area Network) developed by Semtech and the LoRa Alliance. The techniques described herein are not limited to these technologies, but may be used with any number of other cloud transceivers that implement long range, low bandwidth communications, such as Sigfox, and other technologies. Further, other communications techniques, such as time-slotted channel hopping, described in IEEE 802.15.4e may be used.

[0067] Any number of other radio communications and protocols may be used in addition to the systems mentioned for the mesh transceiver 710 and uplink transceiver 714, as described herein. For example, the radio transceivers 710 and 712 may include an LTE or other cellular transceiver that uses spread spectrum (SPA/SAS) communications for implementing high speed communications, such as for video transfers. Further, and number of other protocols may be used, such as Wi-Fi networks for medium speed communications, such as still pictures, sensor readings, and provision of network communications.

[0068] The radio transceivers 710 and 712 may include radios that are compatible with any number of 3GPP (Third Generation Partnership Project) specifications, notably Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), and Long Term Evolution-Advanced Pro (LTE-A Pro). It can be noted that radios compatible with any number of other fixed, mobile, or satellite communication technologies and standards may be selected. These may include, for example, any Cellular Wide Area radio communication technology, which may include e.g. a 5th Generation (5G) communication systems, a Global System for Mobile

Communications (GSM) radio communication technology, a General Packet Radio Service (GPRS) radio communication technology, or an Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology. Other Third Generation Partnership Project (3GPP) radio communication technology that may be used includes UMTS (Universal Mobile Telecommunications System), FOMA (Freedom of Multimedia Access), 3GPP LTE (Long Term Evolution), 3GPP LTE Advanced (Long Term Evolution Advanced), 3GPP LTE Advanced Pro (Long Term Evolution

Advanced Pro)), CDMA2000 (Code division multiple access 2000), CDPD (Cellular Digital Packet Data), Mobitex, 3G (Third Generation), CSD (Circuit Switched Data), HSCSD (High-Speed Circuit-Switched Data), UMTS (3G) (Universal Mobile

Telecommunications System (Third Generation)), W-CDMA (UMTS) (Wideband Code Division Multiple Access (Universal Mobile Telecommunications System)), HSPA (High Speed Packet Access), HSDPA (High-Speed Downlink Packet Access), HSUPA (High-Speed Uplink Packet Access), HSPA+ (High Speed Packet Access Plus), UMTS-TDD (Universal Mobile Telecommunications System - Time-Division Duplex), TD-CDMA (Time Division - Code Division Multiple Access), TD-SCDMA (Time Division - Synchronous Code Division Multiple Access), 3GPP Rel. 8 (Pre- 4G) (3rd Generation Partnership Project Release 8 (Pre-4th Generation)), 3GPP Rel. 9 (3rd Generation Partnership Project Release 9), 3GPP Rel. 10 (3rd Generation Partnership Project Release 10) , 3GPP Rel. 1 1 (3rd Generation Partnership Project Release 1 1 ), 3GPP Rel. 12 (3rd Generation Partnership Project Release 12), 3GPP Rel. 1 3 (3rd Generation Partnership Project Release 13), 3GPP Rel. 14 (3rd Generation Partnership Project Release 14), 3GPP LTE Extra, LTE Licensed- Assisted Access (LAA), UTRA (UMTS Terrestrial Radio Access), E-UTRA (Evolved UMTS Terrestrial Radio Access), LTE Advanced (4G) (Long Term Evolution

Advanced (4th Generation)), cdmaOne (2G), CDMA2000 (3G) (Code division multiple access 2000 (Third generation)), EV-DO (Evolution-Data Optimized or Evolution-Data Only), AMPS (1 G) (Advanced Mobile Phone System (1 st

Generation)), TACS/ETACS (Total Access Communication System/Extended Total Access Communication System), 2-AMPS (2G) (Digital AMPS (2nd Generation)), PTT (Push-to-talk), MTS (Mobile Telephone System), IMTS (Improved Mobile Telephone System), AMTS (Advanced Mobile Telephone System), OLT (Norwegian for Offentlig Landmobil Telefoni, Public Land Mobile Telephony), MTD (Swedish abbreviation for Mobiltelefonisystem 2, or Mobile telephony system 2), Autotel/PALM (Public Automated Land Mobile), ARP (Finnish for Autoradiopuhelin,„car radio phone"), NMT (Nordic Mobile Telephony), Hicap (High capacity version of NTT (Nippon Telegraph and Telephone)), CDPD (Cellular Digital Packet Data), Mobitex, DataTAC, iDEN (Integrated Digital Enhanced Network), PDC (Personal Digital Cellular), CSD (Circuit Switched Data), PHS (Personal Handy-phone System), WiDEN (Wideband Integrated Digital Enhanced Network), iBurst, Unlicensed Mobile Access (UMA, also referred to as also referred to as 3GPP Generic Access Network, or GAN standard)), Wireless Gigabit Alliance (WiGig) standard, mmWave standards in general (wireless systems operating at 10-90 GHz and above such as WiGig, IEEE 802.1 1 ad, IEEE 802.1 l ay, and the like. In adition to the standards listed above, any number of satellite uplink technologies may be used for the uplink transceiver 714, including, for example, radios compliant with standards issued by the ITU (International Telecommunication Union), or the ETSI (European

Telecommunications Standards Institute), among others. The examples provided herein are thus understood as being applicable to various other communication technologies, both existing and not yet formulated.

[0069] A network interface controller (NIC) 716 may be included to provide a wired communication to the cloud 102. The wired communication may provide an Ethernet connection, or may be based on other types of networks, such as Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET, among many others. An additional NIC 716 may be included to allow connect to a second network, for example, a NIC 716 providing communications to the cloud over Ethernet, and a second NIC 716 providing communications to other devices over another type of network.

[0070] The bus 706 may couple the processor 702 to an interface 718 that is used to connect external devices. The external devices may include sensors 720, such as accelerometers, level sensors, flow sensors, temperature sensors, pressure sensors, barometric pressure sensors, and the like. The interface 718 may be used to connect the loT system 700 to actuators 722, such as power switches, valve actuators, an audible sound generator, a visual warning device, and the like. [0071] While not shown, various input/output (I/O) devices may be present within, or connected to, the loT system 700. For example, a display may be included to show information, such as sensor readings or actuator position. An input device, such as a touch screen or keypad may be included to accept input.

[0072] A battery 724 may power the loT system 700, although in examples in which the loT system 700 is mounted in a fixed location, it may have a power supply coupled to an electrical grid. The battery 724 may be a lithium ion battery, a metal- air battery, such as a zinc-air battery, an aluminum-air battery, a lithium- air battery, and the like.

[0073] A battery monitor / charger 726 may be included in the loT system 700 to track the state of charge (SoCh) of the battery 720. The battery monitor / charger 726 may be used to monitor other parameters of the battery 724 to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of the battery 724. The battery monitor / charger 726 may include a battery monitoring integrated circuit, such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488A from ON Semiconductor of Phoenix Arizona, or an IC from the

UCD90xxx family from Texas Instruments of Dallas, TX. The battery monitor / charger 726 may communicate the information on the battery 724 to the processor 702 over the bus 706. The battery monitor / charger 726 may also include an analog-to-digital (ADC) convenor that allows the processor 702 to directly monitor the voltage of the battery 726 or the current flow from the battery 724. The battery parameters may be used to determine actions that the loT system 700 may perform, such as transmission frequency, mesh network operation, sensing frequency, and the like.

[0074] A power block 728, or other power supply coupled to a grid, may be coupled with the battery monitor / charger 726 to charge the battery 724. In some examples, the power block 728 may be replaced with a wireless power receiver to obtain the power wirelessly, for example, through a loop antenna in the loT system 700. A wireless battery charging circuit, such as an LTC4020 chip from Linear Technologies of Milpitas, CA, among others, may be included in the battery monitor / charger 726. The specific charging circuits chosen depend on the size of the battery 724, and thus, the current required. The charging may be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, the Rezence charging standard, promulgated by the Alliance for Wireless Power, among others.

[0075] The mass storage 708 may include a number of modules to implement the rapid loT prototyping functions described herein. Although shown as code blocks in the mass storage 708, it may be understood that any of the modules may be replaced with hardwired circuits, for example, built into an application specific integrated circuit (ASIC). The mass storage 708 may include an automation framework 730, an loT database 732, end point sensor simulators 734, and a control user interface 736. The automation framework 730 runs the simulation by passing simulated events generated by the end point sensor simulators 734 to a simulated loT network. The automation framework 734 populates a tuple in the loT database 732 with a characterization of the simulation. The control user interface 736 is used to define the architectural specifications of simulated loT network, and to define the simulated workload to be processed in the simulation.

[0076] Additionally or alternatively, the mass storage 708 may include a number of modules to implement loT future proofing functions described herein. The mass storage 708 may include an automation framework 730, an loT database 732, end point sensor simulators 734, and a control user interface 736. The automation framework 730 runs the simulation by passing simulated events generated by the end point sensor simulators 734 to a simulated loT network. The automation framework 734 populates a tuple in the loT database 732 with a characterization of the simulation. The control user interface 736 may be used to define the

architectural specifications of simulated loT network, and to define the simulated workload to be processed in the simulation.

[0077] Furthermore, components such as the gateway and various sensors or servers, may be real, virtual, or simulated. Indeed, the representations described with respect to Fig. 7 may be real or simulated with respect to their depiction and in evaluation, including in any hybrid operation of the live real loT components with simulated or emulated components.

[0078] Fig. 8 is a block diagram of a non-transitory, machine readable medium 800 including code to direct a processor to perform rapid prototyping in an loT system. The processor 802 may access the non-transitory, machine readable medium 800 over a bus 804. The processor 802 and bus 804 may be as described with respect to Fig. 7. The non-transitory, machine readable medium 800 may include devices described for a mass storage, such as optical disks, thumb drives, or any number of other hardware devices, also as described with respect to Fig. 7. The non-transitory, machine readable medium 800 may include code 806 to direct the processor 802 to identify a real-world workload, code 808 to convert characteristics of the real-world workload to endpoint simulator workloads, code 810 to generate an event model, and code 81 2 to simulate processing the endpoint simulator workloads. Furthermore, components such as the gateway and various sensors or servers, may be real, virtual, or simulated. Indeed, the representations described with respect to Fig. 5 may be real or simulated with respect to their depiction and in evaluation, including in any hybrid operation of the live real loT components with simulated or emulated components.

[0079] Fig. 9 is a non-transitory, machine readable medium 900 including code to direct a processor 902 to future proof the loT system. The processor 902 may access the non-transitory, machine readable medium 900 over a bus 904. The processor 902 and bus 904 may be as described with respect to Fig. 7. The non- transitory, machine readable medium 900 may include devices described for the mass storage 708 of Fig. 7 or may include optical disks, thumb drives, or any number of other hardware devices.

[0080] The non-transitory, machine readable medium 900 may include code 906 to direct the processor 902 to generate a workflow as described herein. The medium 900 may also include code 908 to generate a simulated loT network, code 910 to generate an event model, and code 912 to future proof the generated workflow. Furthermore, components such as the gateway and various sensors or servers, may be real, virtual, or simulated. Indeed, the representations described with respect to Fig. 9 may be real or simulated with respect to their depiction and in evaluation, including in any hybrid operation of the live real loT components with simulated or emulated components.

[0081]

[0082] Examples are given. Example 1 includes a method of determining headroom for applications includes generating a workflow by modifying a real-world workflow to incorporate a future expectation for the workload, generating a simulated Internet of things (loT) network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, generating an event model for an loT network based on the future proofing workflow, and future proofing the workload and the configuration by simulating an execution of the workflow on the simulated loT network.

[0083] Example 2 includes the method of example 1 , wherein future proofing the workload and the configuration includes generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0084] Example 3 includes the method of examples 1 or 2, wherein the future expectation includes future target workflows.

[0085] Example 4 includes the method of examples 1 or 2, including determining an implication of a future workflow by analyzing statistic characteristics of the simulated execution.

[0086] Example 5 includes the method of example 1 , including predicting nonlinear solution characteristics triggered by varying input parameters.

[0087] Example 6 includes a system for future proofing loT networks including a control user interface to define a simulated Internet of things (loT) network associated with a real loT network, a plurality of sensor simulators to generate events for a future proof workload, and an automation framework to future proof the real loT network by simulating processing of the future proof workload in the simulated loT network.

[0088] Example 7 includes the system of example 6, wherein future proofing the workload and the configuration includes generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0089] Example 8 includes the system of examples 6 or 7, wherein the future expectation includes future target workflows.

[0090] Example 9 includes the system of examples 6 or 7, wherein the automation framework is to determine an implication of a future workflow by analyzing statistic characteristics of the simulated execution.

[0091] Example 10 includes the system of examples 6 or 7, wherein the automation framework is to predict non-linear solution characteristics triggered by varying input parameters.

[0092] Example 1 1 includes a tangible, non-transitory, computer-readable medium including code executable by a processor to direct the processor to generate a workflow by modifying a real-world workflow to incorporate a future expectation for the workload, generate a simulated Internet of things (loT) network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, generate an event model for an loT network based on the future proofing workflow, and future proof the workload and the configuration by simulating an execution of the workflow on the simulated loT network.

[0093] Example 12 includes the medium of example 1 1 . In some examples, the workload and the configuration are future proofed by generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0094] Example 13 includes the medium of examples 1 1 or 12, wherein the future expectation includes future target workflows.

[0095] Example 14 includes the medium of examples 1 1 or 12, including code executable by the processor to determine an implication of a future workflow by analyzing statistic characteristics of the simulated execution.

[0096] Example 15 includes the medium of examples 1 1 or 12, including code executable by the processor to predict non-linear solution characteristics triggered by varying input parameters.

[0097] Example 16 includes an apparatus for representing events that occur in a real world deployment includes means for identifying a real-world workload including a plurality of the events, means for converting a plurality of characteristics of the real- world workload into a plurality of endpoint simulator workloads, means for converting a plurality of gateway hardware characteristics into a plurality of modeling elements for a plurality of simulated Internet of things (loT) networks, means for performing a simulation for each of the endpoint simulator workloads on each of the simulated loT networks, means for collecting statistics about the performed simulation of the simulated loT networks for the endpoint simulator workloads, means for generating a workflow by modifying the real-world workload to incorporate a future expectation for the real-world workload, means for generating a simulated loT network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, means for generating an event model for the simulated loT network based on the future proofing workflow, and means for future proofing the workload and the configuration by simulating an execution of the workflow on the simulated loT network. [0098] Example 17 includes the apparatus of example 16 including means for characterizing a performance of the simulated loT networks for the endpoint simulator workloads.

[0099] Example 18 includes the apparatus of examples 16 or 17, including means for modifying a sensed value of an event in the endpoint simulator workload via a user interface.

[0100] Example 19 includes the apparatus of examples 16 or 17, including means for generating events that trigger multiple simultaneous triggers.

[0101] Example 20 includes the apparatus of examples 16 or 1 7, including means for deterministically simulating multiple triggers.

[0102] Example 21 includes the apparatus of examples 16 or 1 7, including means for deterministically evaluating statistics from simultaneous variations of multiple triggers.

[0103] Example 22 includes the apparatus of example 16, including means for determining the statistics for the simulation. In some examples, the simulation is performed in short durations.

[0104] Example 23 includes the apparatus of example 16, including means for adaptively eliminating workloads and gateway metrics that do not have an impact on the statistics.

[0105] Example 24 includes the apparatus of example 16, including means for performing the simulations in parallel what-if analysis runs.

[0106] Example 25 includes the apparatus of example 24, including means for dynamically coordinating results from executed modules to determine execute sequences.

[0107] Example 26 includes a method of determining headroom for applications includes generating a workflow by modifying a real-world workflow to incorporate a future expectation for the workload, generating a simulated Internet of things (loT) network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, generating an event model for an loT network based on the future proofing workflow, and future proofing the workload and the

configuration by simulating an execution of the workflow on the simulated loT network.

[0108] Example 27 includes the method of example 26. In some examples, future proofing the workload and the configuration includes generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0109] Example 28 includes the method of example 26. In some examples, the future expectation includes future target workflows.

[0110] Example 29 includes the method of example 26, including determining an implication of a future workflow by analyzing statistic characteristics of the simulated execution.

[0111] Example 30 includes the method of example 26, including predicting nonlinear solution characteristics triggered by varying input parameters.

[0112] Example 31 includes a system for future proofing loT networks including a control user interface to define a simulated Internet of things (loT) network associated with a real loT network, a plurality of sensor simulators to generate events for a future proof workload, and an automation framework to future proof the real loT network by simulating processing of the future proof workload in the simulated loT network.

[0113] Example 32 includes the system of example 31 . In some examples, future proofing the workload and the configuration includes generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0114] Example 33 includes the system of example 31 . In some examples, the future expectation includes future target workflows.

[0115] Example 34 includes the system of example 31 . In some examples, the automation framework is to determine an implication of a future workflow by analyzing statistic characteristics of the simulated execution.

[0116] Example 35 includes the system of example 31 . In some examples, the automation framework is to predict non-linear solution characteristics triggered by varying input parameters.

[0117] 36. A tangible, non-transitory, computer-readable medium including code executable by a processor to direct the processor to generate a workflow by modifying a real-world workflow to incorporate a future expectation for the workload, generate a simulated Internet of things (loT) network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, generate an event model for an loT network based on the future proofing workflow, and future proof the workload and the configuration by simulating an execution of the workflow on the simulated loT network.

[0118] Example 37 includes the medium of example 36. In some examples, the workload and the configuration are future proofed by generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0119] Example 38 includes the medium of example 36. In some examples, the future expectation includes future target workflows.

[0120] Example 39 includes the medium of example 36, including code executable by the processor to determine an implication of a future workflow by analyzing statistic characteristics of the simulated execution.

[0121] Example 40 includes the medium of example 36, including code executable by the processor to predict non-linear solution characteristics triggered by varying input parameters.

[0122] Example 41 includes a method of representing events that occur in a real world deployment includes identifying a real-world workload including a plurality of the events, converting a plurality of characteristics of the real-world workload into a plurality of endpoint simulator workloads, converting a plurality of gateway hardware characteristics into a plurality of modeling elements for a plurality of simulated Internet of things (loT) networks, performing a simulation for each of the endpoint simulator workloads on each of the simulated loT networks, collecting statistics about the performed simulation of the simulated loT networks for the endpoint simulator workloads, generating a workflow by modifying the real-world workload to incorporate a future expectation for the real-world workload, generating a simulated loT network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, generating an event model for the simulated loT network based on the future proofing workflow, and future proofing the workload and the configuration by simulating an execution of the workflow on the simulated loT network.

[0123] Example 42 includes the method of example 41 , including characterizing a performance of the simulated loT networks for the endpoint simulator workloads.

[0124] Example 43 includes the method of example 42, including modifying a sensed value of an event in the endpoint simulator workload via a user interface. [0125] Example 44 includes the method of example 41 , further including generating events that trigger multiple simultaneous triggers.

[0126] Example 45 includes the method of example 41 , further including deterministically simulating multiple triggers.

[0127] Example 46 includes the method of example 41 , including deterministically evaluating statistics from simultaneous variations of multiple triggers.

[0128] Example 47 includes the method of example 41 , including determining the statistics for the simulation. In some examples, the simulation is performed in short durations.

[0129] Example 48 includes the method of example 41 , including adaptively eliminating workloads and gateway metrics that do not have an impact on the statistics.

[0130] Example 49 includes the method of example 41 , including performing the simulations in parallel what-if analysis runs.

[0131] Example 50 includes the method of example 49, including dynamically coordinating results from executed modules to determine execute sequences.

[0132] Example 51 includes a method of determining headroom for applications includes generating a workflow by modifying a real-world workflow to incorporate a future expectation for the workload, generating a simulated Internet of things (loT) network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, generating an event model for an loT network based on the future proofing workflow, and future proofing the workload and the

configuration by simulating an execution of the workflow on the simulated loT network.

[0133] Example 52 includes the method of example 51 . In some examples, future proofing the workload and the configuration includes generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0134] Example 53 includes the method of examples 51 or 52, wherein the future expectation includes future target workflows.

[0135] Example 54 includes the method of examples 51 or 52, including determining an implication of a future workflow by analyzing statistic characteristics of the simulated execution. [0136] Example 55 includes the method of examples 51 or 52, including predicting non-linear solution characteristics triggered by varying input parameters.

[0137] Example 56 includes a system for future proofing loT networks including a control user interface to define a simulated Internet of things (loT) network associated with a real loT network, a plurality of sensor simulators to generate events for a future proof workload, and an automation framework to future proof the real loT network by simulating processing of the future proof workload in the simulated loT network.

[0138] Example 57 includes the system of example 56. In some examples, future proofing the workload and the configuration includes generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0139] Example 58 includes the system of examples 56 or 57, wherein the future expectation includes future target workflows.

[0140] Example 59 includes the system of examples 56 or 57, wherein the automation framework is to determine an implication of a future workflow by analyzing statistic characteristics of the simulated execution.

[0141] Example 60 includes the system of examples 56 or 57, wherein the automation framework is to predict non-linear solution characteristics triggered by varying input parameters.

[0142] Example 61 includes a system for representing events that occur in a real world deployment includes a control user interface to define a simulated Internet of things (loT) network associated with a real loT network, a plurality of sensor simulators to generate events for a future proof workload, and an automation framework to future proof the real loT network by simulating processing of the future proof workload in the simulated loT network, wherein the automation framework identifies a real-world workload including a plurality of the events, converts a plurality of characteristics of the real-world workload into a plurality of endpoint simulator workloads, converts a plurality of gateway hardware characteristics into a plurality of modeling elements for a plurality of simulated Internet of things (loT) networks, performs a simulation for each of the endpoint simulator workloads on each of the simulated loT networks, collects statistics about the performed simulation of the simulated loT networks for the endpoint simulator workloads, generates a workflow by modifying the real-world workload to incorporate a future expectation for the real- world workload, generates a simulated loT network for future proofs the workload and a configuration for a simulated gateway of the simulated loT network, generates an event model for the simulated loT network based on the future proofs workflow, and future proofs the workload and the configuration by simulating an execution of the workflow on the simulated loT network.

[0143] Example 62 includes the system of example 61 . In some examples, the automation framework characterizes a performance of the simulated loT networks for the endpoint simulator workloads.

[0144] Example 63 includes the system of examples 61 or 62, wherein the automation framework modifies a sensed value of an event in the endpoint simulator workload via a user interface.

[0145] Example 64 includes the system of examples 61 or 62, wherein the automation framework generates events that trigger multiple simultaneous triggers.

[0146] Example 65 includes the system of examples 61 or 62, wherein the automation framework deterministically simulates multiple triggers.

[0147] Example 66 includes a method of representing events that occur in a real world deployment includes identifying a real-world workload including a plurality of the events, converting a plurality of characteristics of the real-world workload into a plurality of endpoint simulator workloads, converting a plurality of gateway hardware characteristics into a plurality of modeling elements for a plurality of simulated Internet of things (loT) networks, performing a simulation for each of the endpoint simulator workloads on each of the simulated loT networks, collecting statistics about the performed simulation of the simulated loT networks for the endpoint simulator workloads, generating a workflow by modifying the real-world workload to incorporate a future expectation for the real-world workload, generating a simulated loT network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, generating an event model for the simulated loT network based on the future proofing workflow, and future proofing the workload and the configuration by simulating an execution of the workflow on the simulated loT network.

[0148] Example 67 includes the method of example 66 including characterizing a performance of the simulated loT networks for the endpoint simulator workloads. [0149] Example 68 includes the method of examples 66 or 67, including modifying a sensed value of an event in the endpoint simulator workload via a user interface.

[0150] Example 69 includes the method of examples 66 or 67, further including generating events that trigger multiple simultaneous triggers.

[0151] Example 70 includes the method of examples 66 or 67, further including deterministically simulating multiple triggers.

[0152] Example 71 includes the method of example 66, including deterministically evaluating statistics from simultaneous variations of multiple triggers.

[0153] Example 72 includes the method of example 66, including determining the statistics for the simulation. In some examples, the simulation is performed in short durations.

[0154] Example 73 includes the method of example 66, including adaptively eliminating workloads and gateway metrics that do not have an impact on the statistics.

[0155] Example 74 includes the method of example 66, including performing the simulations in parallel what-if analysis runs.

[0156] Example 75 includes the method of example 74, including dynamically coordinating results from executed modules to determine execute sequences.

[0157] Example 76 includes a method of determining headroom for applications includes generating a workflow by modifying a real-world workflow to incorporate a future expectation for the workload, generating a simulated Internet of things (loT) network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, generating an event model for an loT network based on the future proofing workflow, and future proofing the workload and the

configuration by simulating an execution of the workflow on the simulated loT network.

[0158] Example 77 includes the method of example 76. In some examples, future proofing the workload and the configuration includes generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0159] Example 78 includes the method of examples 76 or 77, wherein the future expectation includes future target workflows. [0160] Example 79 includes the method of examples 76 through 78, including determining an implication of a future workflow by analyzing statistic characteristics of the simulated execution.

[0161] Example 80 includes the method of example 76, including predicting nonlinear solution characteristics triggered by varying input parameters.

[0162] Example 81 includes a system for future proofing loT networks including a control user interface to define a simulated Internet of things (loT) network associated with a real loT network, a plurality of sensor simulators to generate events for a future proof workload, and an automation framework to future proof the real loT network by simulating processing of the future proof workload in the simulated loT network.

[0163] Example 82 includes the system of example 81 . In some examples, future proofing the workload and the configuration includes generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0164] Example 83 includes the system of examples 81 or 82, wherein the future expectation includes future target workflows.

[0165] Example 84 includes the system of examples 81 through 83, wherein the automation framework is to determine an implication of a future workflow by analyzing statistic characteristics of the simulated execution.

[0166] Example 85 includes the system of examples 81 or 82, wherein the automation framework is to predict non-linear solution characteristics triggered by varying input parameters.

[0167] Example 86 includes a tangible, non-transitory, computer-readable medium including code executable by a processor to direct the processor to generate a workflow by modifying a real-world workflow to incorporate a future expectation for the workload, generate a simulated Internet of things (loT) network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, generate an event model for an loT network based on the future proofing workflow, and future proof the workload and the configuration by simulating an execution of the workflow on the simulated loT network.

[0168] Example 87 includes the medium of example 86. In some examples, the workload and the configuration are future proofed by generating a model of future applications, and simulating an execution of the workflow on the simulated loT network using the model of future applications.

[0169] Example 88 includes the medium of examples 86 or 87, wherein the future expectation includes future target workflows.

[0170] Example 89 includes an apparatus for representing events that occur in a real world deployment includes means for identifying a real-world workload including a plurality of the events, means for converting a plurality of characteristics of the real- world workload into a plurality of endpoint simulator workloads, means for converting a plurality of gateway hardware characteristics into a plurality of modeling elements for a plurality of simulated Internet of things (loT) networks, means for performing a simulation for each of the endpoint simulator workloads on each of the simulated loT networks, means for collecting statistics about the performed simulation of the simulated loT networks for the endpoint simulator workloads, means for generating a workflow by modifying the real-world workload to incorporate a future expectation for the real-world workload, means for generating a simulated loT network for future proofing the workload and a configuration for a simulated gateway of the simulated loT network, means for generating an event model for the simulated loT network based on the future proofing workflow, and means for future proofing the workload and the configuration by simulating an execution of the workflow on the simulated loT network.

[0171] Example 90 includes the apparatus of example 89 including means for characterizing a performance of the simulated loT networks for the endpoint simulator workloads.

EXAMPLES OF CODE

[0172] The following are only examples and not intended to limit the present techniques. There may be multiple files which run on a device according to the role of the device (client, gateway, or server). In the following example, the code determines solution characteristics for a given set of input workflow parameters and gateway characteristics.

[0173] The following code examples include one set of code sections that performs future proofing of loT networks, and one set of code sections that perform rapid prototyping of loT networks. Future proofing is identifying an architecture that meets the SLA conditions of a potential future workflow. In an example of future proofing, Code Sections 1 -4 determine gateway characteristics that accommodate a given set of input workflow parameters, and expected solution characteristics. These workflow parameters are the set of parameters that a current deployment could use sometime in the future. The expected solution characteristics may be expectations of what a future loT network architecture may include.

# Find optimal gateway config for a given set of workflow and solution parameters.

# ML equation: Gi = Wi + Si

# Based on the input workflow parameters and expected solution characteristics,

# calculate gateway characteristics needed for that solution outcome using Machine

Learning,

import numpy as np

import statsmodels.api as sm

import xlrd

import pandas as pd

import math

import time

import os

CODE SECTION 1

[0174] Code Section 2 performs linear regressions. There are several independent parameters that will influence a given dependent parameter and the relationship may be a non-linear relationship. In examples, the application of Code Section 2 to edge devices provides for the determination of solution parameters, gateway configuration, publishing characteristics and such to determine an efficient configuration.

#Function to run multiple linear regression

def reg_m(y, x):

ones = np.ones(len(x[0]))

x = np.array(x).T

x = sm.add_constant(x)

#Linear Regression results = sm.OLS(endog=y, exog=x).fit()

print "\n ==================================== \n"

print ("The coefficients

are : ", results. params)

print ("The STD errors are : ", results. bse)

print ("The scale is: ", results.scale)

print ("The std_error (sqrt(scale)) is: ", math.sqrt(results.scale))

print "\n ===================================== \n"

#print results. summaryO

return results

CODE SECTION 2

[0175] It is noted that Code Section 3 determines gateway characteristics. However, this is merely one example of an architecture element that may be determined. Examples may also, or alternatively, determine the characteristics of other elements of an loT network architecture.

#Function for Gateway Characteristics calculation

def gw_calc(data, const, sensor, pub, burst, std_err):

# Create global list of predicted GW CPU values that can be used to predict required future GW Architecture,

global Pred_GW_array = []

GW_counter = 0 for arr in data:

Calculate predicted GW CPU Freq

pred_gw_freq = const + (arr[0] ^* sensor) + (arr[1 ] ^* pub) + (arr[2] ^* burst) print ("Calculated GW_CPU_Freq is: ", pred_gw_freq)

Pred_GW_array[GW_counter] = pred_gw_freq

GW counter += 1 return print "Learning in progress..."

CODE SECTION 3

#Read Workflow and Solution data from Excel sheet, workbook = xlrd.open workbook('ProfiledData.xlsx') worksheet = workbook. sheet_by_name('Solution') num cols = worksheet. ncols 1

#Create an array to store all the cols.

Sensor array = []

Publish array = []

Burst_array = []

CPlLarray = []

S_array = []

P_array = []

B array = []

A array = []

#Add each column to an array.

S_array += worksheet.col(O)

P_array += worksheet.col(1 )

B array += worksheet.col(2)

A array += worksheet.col(3) for S in S_array:

Sensor array.append(S.value)

for P in P array:

Publish array.append(P.value)

for B in B array:

Burst_array.append(B. value)

for A in A array: CPU_array.append(A.value)

#Create Predictor array and independent variables, y = CPU_array

x = [Sensor array, Publish array, Burst_array]

#Run regression on the input data,

results = reg_m(y, x)

#Capture the coefficients.

Reg_const = results.params[0]

Reg_sensor = results. params[1 ]

Reg_pub = results. params[2]

Reg_burst = results.params[3]

#Document required Solution and Workflow characteristics #Read Workflow and Solution data from Excel sheet, workbook = xlrd.open workbook('FutureData.xlsx') worksheet = workbook. sheet_by_name('Solution') num cols = worksheet. ncols 1

#Create an array to store all the cols.

Sensor array = []

Publish array = []

Burst_array = []

S_array = []

P_array = []

B array = []

#Add each column to an array.

S_array += worksheet.col(O)

P_array += worksheet.col(1 )

B array += worksheet.col(2) for S in S_array:

Sensor array.append(S.value)

for P in P array:

Publish array.append(P.value)

for B in B array:

Burst_array.append(B. value)

# Create input to ML equation.

# List of Lists, with each nested list having a value from each category

test_arr = list(zip(Sensor_array, Publish array, Burst_array))

# Calculate Gateway characteristic.

gw_calc(test_arr, Reg_const, Reg_sensor, Reg_pub, Reg_burst,

math.sqrt(results.scale))

CODE SECTION 4

[0176] In the following example, the Code Sections 5-9 perform rapid prototyping of loT networks. Specifically, the solution characteristics for a given set of workflow and gateway parameters are estimated.

# Find estimated solution characteristics for a given set of workflow and gateway parameters.

# ML equation: Si = Wi + Gi

# Based on the input workflow parameters and gateway characteristics

# calculate solution characteristics using Machine Learning import numpy as np

import statsmodels.api as sm

import xlrd

import pandas as pd

import math

import time

import os #Function to run multiple linear regression

def reg_m(y, x):

ones = np.ones(len(x[0]))

x = np.array(x).T

x = sm.add_constant(x)

#Linear Regression

results = sm.OLS(endog=y, exog=x).fit()

print "\n ==================================== \n"

print ("The coefficients

are : ", results. params)

print ("The STD errors are : ", results. bse)

print ("The scale is: ", results.scale)

print ("The std_error (sqrt(scale)) is: ", math.sqrt(results.scale))

print "\n ===================================== \n"

#print results. summaryO

return results

CODE SECTION 5

[0177] Code Section 6 shows CPU prediction as one example of how

determinations can be done. Similar approaches may be used to make

determinations with regard to memory, storage, bandwidth, software, and any other element of an architecture.

#Function for Solution Characteristics (CPU_Total) calculation

def Soln_calc(data, const, sensor, pub, burst, std_err):

for arr in data:

#calculate predicted Solution CPU

pred_soln_cpu = const + (arr[0] ^* sensor) + (arr[1 ] ^* pub) + (arr[2] ^* burst) print ("Calculated CPU_Total is: ", pred_soln_cpu) return

print "Learning in progress..."

CODE SECTION 6

#Read Workflow and Gateway profile data from Excel sheet, workbook = xlrd.open workbook('RegressionData.xlsx') worksheet = workbook. sheet_by_name('Test')

num cols = worksheet. ncols 1

#Create an array to store all the cols.

Sensor array = []

Publish array = []

Burst_array = []

Act_CPU_array = []

S_array = []

P_array = []

B array = []

A array = []

#Add each column to an array.

S_array += worksheet.col(O)

P_array += worksheet.col(1 )

B array += worksheet.col(2)

A array += worksheet.col(3) for S in S_array:

Sensor array.append(S.value)

for P in P array:

Publish array.append(P.value)

for B in B array:

Burst_array.append(B. value)

for A in A array: Act_CPU_array.append(A.value)

#Create Predictor array and independent variables,

y = Act_CPU_array

x = [Sensor array, Publish array, Burst_array] CODE SECTION 7

[0178] Code Section 8 represents a regression run. The outputs of the regression runs are the predictors for the parameters of interest. These resultant parameters are the solution characteristics as observable in a deployment.

#Run regression on the input data,

results = reg_m(y, x)

#Capture the coefficients.

Reg_const = results.params[0]

Reg_sensor = results. params[1 ]

Reg_pub = results. params[2]

Reg_burst = results.params[3]

CODE SECTION 8

[0179] Code Section 9 detects the actual workflow. This is accomplished using profilers that detect parameter values such as publish rates, payload, header characteristics, CPU, memory usage etc.

#Detect workflow coming in to gateway.

global count,g_avg_pub_freq,g_aprx_pub_freq,g_avg_burst_count,pub_m sg count = (count%10) + 1

for i in range(len(time_list)1 ):

time2 = time_list[i+1 ].split(" ")[0]

timel = time_list[i].split(" ")[0] exec_time = float((datetime.datetime.strptime(time2, FMT)

datetime.datetime.strptime(time1 , FMT))total_seconds()) execjime ^* = 1000

exec_time_list.append(exec_time)

os.system("clear")

cmd = "netstat lantp | grep E 'mosquitto. ^* ESTABLISHED|ESTABLISHED. ^* mosquitto'

I grep -v '127.0.0.1 ' |wc I"

proc=Popen(cmd,shell=True,stdout=PIPE, )

num_sensor=int(proc.communicate()[0]) 1

avg_burst_count = sum(burst_count)/len(burst_count)

if (g_avg_burst_count == 0):

g_avg_burst_count = avg_burst_count

else:

g_avg_burst_count = g_avg_burst_count + ( float(avg_burst_count

g_avg_burst_count) / count) avg_pub_freq = sum(interval_list)/len(interval_list)

if (g_avg_pub_freq == 0):

g_avg_pub_freq = avg_pub_freq

else:

g_avg_pub_freq = g_avg_pub_freq + ( float(avg_pub_freq g_avg_pub_freq) / count)

print "Number of sensors: ",num_sensor

print "Avg publish interval: "+ str(g_avg_pub_freq)+" seconds"

print "Avg Burst Count: "+str(g_avg_burst_count)

cpu_usage = psutil.cpu_times_percent().user

print "CPU Usage: "+str(cpu_usage)

data_string =

str(num_sensor)+','+str(int(round(g_avg_pub_freq)))+','+s tr(int(round(g_avg_burst_c ount)))+','+str(int(cpu_usage))

array = []

array.append(data_string.strip().split(','))

test_arr = [map(int, x) for x in array] #Calculate Solution characteristic.

Soln_calc(test_arr, Reg_const, Reg_sensor, Reg_pub, Reg_burst, math.sqrt(results.scale))

CODE SECTION 9