REQUEST ACCESS

MachineShop Introduction

Platform Introduction

Within that “last mile bridge” that supports devices in the field, MachineShop provides Edge Computing services that support: data management, device management, and orchestration.  

Initial Concepts

API First:  

Most platforms offer only a all-in-one software package. Having an API strategy enables our customers to integrate only the needed services into their own/legacy applications.  MachineShop exposes a wide variety of RESTful API's to enable applications to easily integrate with our solution.


JSON is King:  

REST and JSON are a standard of many modern applications and, as such, it’s easy to “slurp” and work with.  So, while there are many protocols that MachineShop interacts with, there is an internal JSON standard to MachineShop.  Regardless of where the data came from (a device using MODBUS, OPC-UA, or some other protocol), the data is translated in MachineShop and is managed as JSON.  This allows for logical layers to be easily laid upon the data that flows in.  It also makes it easy to take the standardized JSON data and push it up into any cloud-based platform.


Non-Structured Data with possible Relationships:   

Many other platforms use traditional Schema-based databases which require them to try to fit an irrational data model into a very structured database with horrible results.  MachineShop takes advantage of a non-structured database which provides incredible flexibility and scalability while also allowing for relationships to be layered on top of the database which enables faster and more resource constrained queries.  


Pillars of Functionality

Device Manager:  

The hardware that sits at the edge can communicate in different protocols and has a variety of different operating systems as well as different processes for saving and updating their images.  Much of that complexity is simplified by using MachineShop to "group" devices into overlapping categories.  Also, many of these remote device support processes are proprietary and to support these needs, MachineShop has a flexible platform that allows for modular additions of custom code to support a wide variety of different edge device management scenarios.



Data Manager:  

Edge devices communicate in a variety of different protocols.  The search for a common IoT protocol or language is about as realistic as the idea that all humans will speak the same language, in the same way at the same time. Vertical device markets are all governed by different standards bodies. Vendors are constantly looking for any subtle difference that will separate them from their competitors. Also, there are decades of legacy systems that can’t just magically change the way they communicate.  MachineShop brings order to this chaos by translating different communication protocols into one standard JSON format.  Like device management, if the protocol is proprietary, then there is a way to add a modular translation component to the product.


Orchestration

Data may only have a “virtual weight”; however, moving it from the edge to the cloud has a very real expense.  The latency of communication between a device or gateway at the edge to the cloud can have real-world impact as well.  MachineShop is The Edge Computing Company in part because we own the management of data within the edge devices.  Do you need to let that data “drop to the floor” and be forgotten, store it locally, transform it, send it to one or more cloud-based applications or all of the above?  MachineShop’s orchestration layer evaluates information coming from devices "in context" and make intelligent decisions which could include changing a devices behavior locally based on information that it is reporting.



Full Butt Load of User Story Examples:

If each user story were to weigh a gallon, then it would take 104 gallons to fill two hogsheads (or make one butt load)...see:  https://gizmodo.com/butt-is-an-actual-unit-of-measurement-1622427091


With that in mind, the team at MachineShop is going to work on a library of 104 user stories to show the flexibility of the platform.


Use Case 1:  Vending Machines

The first IoT device was a vending machine at Carnegie Mellon’s computer science department in 1982.  With that bit of history, we’ll start the use cases with a customer that provides the gateway hardware in vending machines.  This hardware includes a “gateway router” that the customer manages remotely.  To complicate things, these devices are being distributed worldwide and need to have the firmware updates specific to carriers in various countries. Finally, because of the cost and availability of on-site technical expertise, the customer needs a hardware and software solution that allows the lowest cost technicians to be able to simply plug the hardware in and allow for all of the systems management to occur remotely.  


MachineShop provides easy remote systems management and if a future gateway hardware / firmware change were to cause a need for different API calls, MachineShop can easily manage this complexity.


The APIs used (and why they are used) for this use case are described below:

1. /users

Users are a primary entity in MachineShop and these are used to provide visibility and permissions.
2.  /gateway_data_source_types

There are different models of gateways.  Some of these are hardware generations and some of the differences depend on the local cellular provider and the updates that they provide.  The result is a very complex grouping excercise that data_source_types simplifies.  

3. /gateway_data_sources 

This is used to manage all aspects of a specific device as well as the current reported state of the device.  

4. /data 

This endpoint pulls historical reports of the equipment (for example: give me reports from the beginning to the end of last year).

5. /commands 

This sends commands to change the operating conditions of a device (like adjusting the operating temperature of a vending machine).   

6. /gateway_configs 

Some vending machine gateways are configured differently than others.  This endpoint allows for these different configurations to be filtered and viewed as groups.  This also used for initial "zero touch configuration".  You can set up a profile and have it applied to any new gateways that come online.  No local user interaction is required.

 

Use Case 2:  Water Purity and Chemistry

Another customer allows their users to create manage hardware as a service (HaaS)...a single hardware platform that has capabilities enabled via software controls.  

This customer sells water purification hardware and software to customers. These systems include pumps, sensors, chemical injectors, and an application to interact with. The lower-cost sensors available are not easily integrated into the solution because of protocol challenges; however, using MachineShop’s platform Milwaukee integrates the various components using lower-cost hardware.  All of this is “invisible” to the typical user interface from within the customer’s application where they can observe the results that measure and maintain (Ph, temperature, pump speed, etc) as well as a host of other attributes their users need from within a single pane of glass.

1. /users

Users are a primary entity in MachineShop and these are used to provide visibility and permissions.

2. /data_source_types 

There are 3 different models of units and this endpoint allows for differentiation between these different unit types.

3. /data_sources 

This endpoint refers to the specific Milwaukee device...as a source of data.

4. /data 

This endpoint pulls historical reports of the equipment (for example: give me reports from the beginning to the end of last year).

5. /rules 

This is an orchestration rule that notifies users about pump and injector behavior as well as sends reports to a cloud-based application for analysis in the cloud.

6. /commands 

Adjusts the overall behavior of the device. This is primarily used to send the information that their software would use locally to make decisions on turning pumps on/off.

7. /email 

Allows for sending email notifications to users based on condition of the equipment being monitored by the device. 

8. /sms 

Allows for sending SMS notifications to users based on condition of the equipment being monitored by the device. 

9. /generic_storage 

For this example there is nothing persisted at the edge. They use our generic data storage as a simple data store for their custom application. This means they do not need to maintain their own database making it easier to deploy and lowering the overall costs. 



Use Case 3:  Security Alarms

We have one customer that has been selling security hardware and software for three decades. Over the years, the hardware, software and functionality have changed dramatically. Nonetheless, this customer needed a simple way to manage all those different devices in the field. MachineShop provides an API extrapolation layer so that one identical call from the security company’s application that calls “arm alarm” and gets a response from MachineShop after the edge provides the right command, in the right format to arm the correct device in the field. This dramatically simplifies the security company’s integration efforts initially. Furthermore, these “last mile protocols” are living, breathing standards that continue to adapt.  It is MachineShop’s job to keep up with these standards and we remove this ongoing maintenance from our customer’s maintenance efforts.


The APIs used for this use case include:

1. /data_source_types

This is used to define the various types of alarm hardware and manage their communication as a group (this type uses one set of commands, this other type uses a different set of commands).  This is the heart of the API extrapolation layer for the web application the customer built.

2. /data_sources 

This endpoint refers to the specific alarm device...this is the lowest level of hardware status and reports for this customer.

3. /rules 

This customer uses rules in the cloud for notification of events and to auto send commands back to devices to change device behavior.

4. /commands

This endpoint changes the device behavior of devices within the security alarm system.  

5. /email

This endpoint allows for an email platform integration.

6. /sms

This customer has scenarios that trigger an SMS call.

REQUEST ACCESS

Get Started Today

HyperEdge is available for a wide variety of linux distributions and processors. Get more information on how you can gain access to a developer version of HyperEdge.

GET STARTED