Manufacturing Big Data

System Insights Corporate Blog

Green Supply Chain Management

Designing and implementing sustainable supply chains is gaining importance these days, as depleting natural resources and increasing climate change risks have emphasized the need for eco-friendly manufacturing practices. The process of integrating environmental drivers into Supply Chain Management (SCM) is called Green Supply Chain Management. Green Supply Chain Management is motivated by:

  • Diminishing raw materials
  • Increased material waste and disposal
  • Increasing environmental awareness among stake holders
  • Being competitive among peers

Green Supply Chain Management focuses on identifying and minimizing the wastes generated in entire supply chain process. The waste reduction strategy could be long term or short term. The long term options are more strategic and the short term options are more tactical.

Implementing Green Supply Chains

Greening the supply chain involves the following processes:

  • Green Design – Designing a product/service that is environmentally sustainable
  • Green Purchase – Selecting a product/service that will minimise negative environmental impact over the life cycle
  • Green Manufacturing – Implementing manufacturing processes which lead to a reduction in energy consumption, resource consumption, waste by-products, and water usage
  • Green Distribution – Reducing environmental impacts in packaging and logistics
  • Reverse Logistics – Retreiving the product from the end consumer for the purposes of capturing value or proper disposal


  • Improves environmental efficiency
  • Increase reuse/recycle of waste
  • Reduces waste for disposal
  • Raw material and resource conservation
  • Improves cost competitiveness
  • Reduce GHG emission levels

How vimana helps

System Insights develops vimana, the predictive analytics platform for manufacturing intelligence. System Insights delivers compelling value to manufacturing enterprises across multiple verticals around the world, by increasing asset utilization, reducing operational costs, and improving profitability. Enhancing manufacturing sustainability is one of the key values that vimana delivers. vimana provides visibility into manufacturing processes and process flows and helps identify and reduce waste in the value stream and supply chain.

ED3152 @ IIT Madras

I am teaching the course ED3152: Precision Processes and Systems at IIT Madras. You can follow the course material and discussions on the course website.

The Next Generation of American Manufacturing

Steve Fritzinger, NetApp’s Virtualization Alliance Manager, Java Author and Economics Writer, discusses the future of American manufacturing with Penny Brown from IMTS TV. America is by no means a laggard in the world of manufacturing; we are very competitive and with a proper educational foundation and technology, we can retain our position and exceed our current standing. But in order to do so, American manufacturing must adapt to survive.

At the heart of this revolution is technology. The new manufacturing jobs will be more technical and require increasingly skilled labor. The machines and technology will do the simple tasks, leaving our labor force to focus on performance, new processes, and materials. Standards and standards based solutions will enable this revolution because manufactures will have the ability to leverage a wider choice of solutions that specifically address their needs.

Unlike the current situation, each product shares a common infrastructure with no additional per-product cost for connectivity. As well, this reduces the barrier of entry for new products and services, so there are more options and faster deployment. In the end the market grows as the demand increase, creating a larger aggregate for everyone.

Our product, vimana, exclusively uses standard based data collection to drive our analytics platform. We believe that promoting the industry and developing standards will increase the understanding of what is possible and in the end will push the boundaries of the industry. If the industry is more advanced, then our solutions will be able to leverage an informed market that is asking for ways to improve and compete effectively, regardless of where they’re located.

MTConnect Releases a New Video From MC[2]

Excellent video from MC 2 conference staring Jake Ervin. This was shot at the MC 2 conference in April and Jake, sadly, trying to strike up a meaningful conversation with a machine tool. I make a cameo at the end of the video. After watching myself, I’ve lost all aspirations of acting. Better stick to my day job!

MTConnect ROS-I Robot CNC Integration

Robotic Interface – Machine Tool Perspective

This work was conducted under Grant Opportunity Number 2012-NIST-MSE-01 for the Intelligent System Division of the National Institute of Standards and Technology (NIST) with the collaboration of System Insights, SwRI (Southwest Research Institute), NCDMM (National Center for Defense Manufacturing and Machining), AMT (Association for Manufacturing Technology) and Mazak USA for help with connectivity of the machine tool used in the demonstration.

From the machine tool perspective, the Robot is an external entity that loads and unloads material into and from its work-holding. This function can be carried out by a person, a robot, a mobile material handler, an operator, or a highly trained golden retriever. The machine does not care how the material is supplied, just that the task has been completed so it can start its cutting cycle.

The innovation in the MTConnect interface is the ability to abstract the task being performed from the underlying implementation necessary to complete the task. To load material into a machine tool, the robot has to have knowledge of the location of the work-holding and the necessary approach angles as well as any collision domains within the machine enclosure. From the machine tools perspective, this is all inconsequential as long as it gets its material.

Once complete, the machine tool needs to be able to ask for the material to be removed. This is also accomplished at the higher level by requesting the material get unloaded. At that point, the machine tool does not care where the material is going; it only needs to request another piece of material for subsequent processing. It is up to the Robot sequence the material to the next station.

From the Robot’s perspective, it knows how to pick up a new piece of material and place it in the machine tool and where to place the material once it has removed it. It has two needs that need to be fulfilled from the machine tool, opening and closing the door and opening and closing the chuck.

The “interfaces” provided by each device is as follows:

Machine Tool Requests:

  1. LoadMaterial
  2. UnloadMaterial

Robot Requests:

  1. OpenDoor
  2. CloseDoor
  3. OpenCluck
  4. CloseChuck

The rational for having the Robot make the requests of the machine tool is the reduction of failure due to timing related issues. When the machine tool has requested the material load and unload, it has no way to sense the location of the robot and the presence of material in the chuck. When the Robot begins its cycle it checks the current door state, if the door is closed, it will request the machine tool open the door. It may also ask the machine tool to open the chuck at the same time. The machine tool will respond with an Active → Complete sequence stating that it has completed the task or it will Fail if it is incapable.

The Robot requires the machine to be have the door and the chuck must be open before it can insert material. Once the material is in place, the Robot asks the machine tool to close the chuck. It must not release the material until the chuck is closed or else it will be dropped. The machine tool will track the state of the chuck and a positive engagement before it changes the chuck state and signals the task as complete.

The same goes for the door; the machine tool has no knowledge of the position of the Robot and therefore does not know when the Robot is safely outside the enclosure. The Robot therefor asks for the door to be closed once it knows there are no issues. This decouples the issue of load completion timing with the door actuation.

Messaging at this higher semantic level provides the basis for a lighter weight protocol that has simplified failure recovery scenarios and less coupling of inter-related components. Decoupling of components allows us to more readily replace parts of the system, like replace the Robot or the machine tool with another device that can perform the required activity and have the interface layer stay the same.

Machine Tool Architecture Overview

The MTConnect CNC architecture consists of three components – the MTConnect adapter for the machine tool to report states, the MTConnect agent to provide MTConnect protocol and XML formatting, and the Interface Control Layer (ICL) that listens to other devices and coordinates the activities. The adapter and agent are the standard out-of-the box MTConnect components for the machine tool. Minor additions were made to the adapter to support chuck state for use in this project. That addition will be proposed to the MTConnect standard in future versions (more on that later.)

Figure 1

Figure 1

The ICL layer is a client of both the CNC agent and the Robot agent and publishes only the state of the interface data items. This allows us to relegate the machine status to the machine tool and separate out the responsibility to react to the changes in the state of both robot and CNC to the ICL layer. This layer also instructs the machine tool to do one of the following six operations:

  1. Open Door
  2. Close Door
  3. Open Chuck
  4. Close Chuck
  5. Start Cycle
  6. Reset/Stop Cycle

These actions are invoked on the machine tool controller by sending the instructions that resolve into the PLC or API specific operations. For the demonstration at NIST, this was accomplished by invoking a small utility on the controller the set various PLC registers to actuate the chuck, cycle start and reset. We could not open and close the door because the machine was not equipped with an actuator; to do so would have incurred a large additional cost. The door behavior was therefore synthesized for the demonstration.

Messaging Architecture

Figure 2

Figure 2

MTConnect uses a very simple messaging architecture based on the MTConnect read-only philosophy. Instead of sending a message requesting an action be performed or setting a variable on a remote device, MTConnect has each device announce its needs to any application or device monitoring its state. In effect, the request interface is a simple state machine that goes from NOT_READY to READY. And when the interface would like the activity performed, it transitions to Active.

In turn, it waits for the device performing the activity, the responder, to announce it is actively performing the activity and then to change to the complete state when its done. This provides the basis for the coordination of actions between devices. Currently this scheme has been tested between two devices paired directly. In the future enhancements section of this report, we will discuss some ideas to extend this paradigm to multiple interconnected devices supporting cells or even swarms of devices in a mobile environment.

Figure 1 shows the state transitions and intermediate as well as terminal states. This model is currently implemented using an MTConnect Event with the subType of REQUEST or RESPONSE to indicate its behavior. In the next section we will have a more in-depth discussion of the failure scenarios and how recovery is to be handled. The MTConnect machine tool simulator and state machine implements many of these scenarios and references to the actual implementation will be provided.

Figure 3

Figure 3

In the MTConnect standard, the current state of a device can be determined by making an HTTP request and specifying the device name and current, for example: http://localhost:5000/cnc/current will provide the current state of the “cnc” device on the local machine. The result will come back to the client or requestor in XML which they can then parse to find the information they need. From that point on, near-real-time data can be received on a push basis (meaning there is no need to poll) using the MTConnect streaming capability using the sample request. To get a completely contiguous data set, one uses the nextSequence number presented in the current to begin the push based request as follows:


This will provide data immediately after it arrives (usually within 3ms) to the client. The interval=0 means never delay and wait for additional data to arrive before sending out the updates. It is usually best accompanied by a filter to make sure we don’t load the communications or the processes unnecessarily. This can be done by providing a path as an argument.


The example will give us only the controller mode, chuck state, execution, conditions, as well as all the information from the interfaces. This is the full set of data required by the Robot to operate.

For the purposes of this discussion, we will focus on the interfaces and a few key Computer Numerically Controlled Machine Tool (referred to as CNC) and Robot states that are required for coordination of interaction. The following is based on the implementation of interfaces for the ROS/I MTConnect demonstration. For more information on streaming data handling and event processing, please consult Part 1 of the MTConnect standard.

State Machines

The implementation of the machine tool ICL consists of 7 state machines, they are as follows:

  1. Top level machine tool
  2. Material load
  3. Material unload
  4. Open chuck
  5. Close chuck
  6. Open door
  7. Close door

The top level state machine controls the main operational and non-operation states of the machine tool. There are two top-level states the machine can be in, disabled and operational. In the disabled state there are two sub-states, “not-ready” and “fault”. When the machine tool has an alarm active, the state machine is in a “fault” state. The other disabled state is “not-ready” which is when the machine tool is not in AUTOMATIC controller mode or is not ready to execute the part program.

The operational states are one of the following: “idle”, “cycle_start”, “loading”, or “unloading”. The machine tool becomes operational when the machine tool’s controller mode is in AUTOMATIC and it is ready to run the part program. If the robot is interfaces are NOT_READY, the machine tool will remain in an “idle” state until the robot interfaces are READY. When the robot interfaces are READY, the machine tool will transition into the “loading” or “unloading” states depending on whether the machine has material.

Once the machine completes the material load, it will transition into a cycle start state. The cycle start state will transition once the cycle is complete indicated by the execution transitioning from active to ready. The machine will then go into an unloading state signaling the robot to remove the material.

Figure 4

Figure 4

The other 6 state machines represent two interface types, request and response. We have two requests (load and unload) and four responses (open/close chuck and door). For this discussion we will be presenting only one representation of each, the open door and the material load.

The response state machine consists of a single level where the states are equivalent to the MTConnect interface proposal. The states are not_read, ready, active, complete, and fail. The feedback from the machine tool’s state variable (DoorState in this instance) will trigger the transitions from active to complete. Since we did not have a real door actuator, this was simulated by a timer. The chuck state did operate off of the machine tool chuck’s solenoids.

The door interface values will track the states in this state machine and are modified directly in this module. The rest of the states and transitions are managed externally by the top level state machine or the machine tool itself. One additional feature of this state machine is it will coordinate with its inverse operation and validate they are not both active at the same time. So, in the case of the open door interface, the close door interface will fail if the open door is currently active. The door cannot be opening and closing at the same time.

Most of the complexity in the response state machine is handling of failures. If anything goes wrong on the robot or machine tool side, we immediately fail. The failure signal is used to indicate a fault has occurred and transitions into a fail state. In both the request and the response, a fail transition will transition the top level state machine into a failure if the operation is active. More discussion will be provided in the Failure and recovery section of this document.

Figure 5

Figure 5

The second class of state machine is the request. The request is in one of the following states, not-ready, active, processing, fail, and ready. All states except for processing are direct parallels to the proposed changes to the MTConnect standard, the processing state tracks the active state on the Robot and transitions to not ready once the operation is complete. The reason we transition to not-ready instead of ready is because once the material has been successfully loaded, we cannot load again, therefor the interface is now not available until the machine has been unloaded.

Figure 6

Figure 6

Failure and Recovery

This section will discuss the different operational scenarios of the machine tools. Since all states and transitions can be derived from the events that occur from the state changes in robot and the machine tool, we will present the code used to test the state machine and the expected behavior. These “tests” will serve as the basis of the behavioral documentation for the MTConnect interface definition in the subsequent versions of the standard.

The first set of scenarios will present the positive cases where we will show the successful operation of the door and the chuck. The later cases will walk through the steps demonstrating what happens when a component fails and what the recovery scenario is. All examples are “runnable”, meaning they have been executed and validated with the current implementation of the machine tool state machine.

For all the tests, we make sure the devices are in an operation state before we begin our scenarios. Otherwise the machine tool interfaces will be non-operational. The initiation sequence of events are as follows:

    Given robot Availability is Available
    And robot ControllerMode is Automatic
    And robot Execution is Active
    And robot MaterialLoad is Ready
    And robot MaterialUnload is Ready
    And robot OpenDoor is Ready
    And robot CloseDoor is Ready
    And robot OpenChuck is Ready
    And robot CloseChuck is Ready
    And cnc ControllerMode is Automatic
    Then cnc MaterialLoad should be Active
    And cnc MaterialUnload should be Not_Ready

The machine tool is now in an operational state waiting to have material loaded. This is asserted using the following expression and will precede all scenarios.

  Background: Machine Tool and Robot are operational
    Given Devices are in initial state

Actuation of the door and chuck are operationally separate for the loading and unloading of material. When the machine is in cycle the door may not open as well as the chuck being locked. But at other times the robot is free to request the machine tool open and close the chuck and door to fulfill its needs. The following scenarios test these functions.

  Scenario: Robot asks Cnc to Open Door
    Given cnc MaterialLoad should be Active
    When robot OpenDoor becomes Active
    Then cnc DoorState should be Open

  Scenario: Robot asks Cnc to Open Chuck
    Given cnc MaterialLoad should be Active
    When robot OpenChuck becomes Active
    Then cnc OpenChuck should be Active
    When cnc ChuckState becomes Unlatched
    When cnc ChuckState becomes Open
    Then cnc ChuckState should be Open

The following is the full scenario of a material load with chuck and door operations. Once the robot completes the material load, we validate that the machine tool starts the cycle.

  Scenario: Cnc asks Robot to Load Material
    Given cnc MaterialLoad should be Active
    When robot MaterialLoad becomes Active

The following code statement validates the state of a given state machine.

    Then material load state should be processing

The following steps open the door and make sure we’re still in a loading state.

    And cnc DoorState should be Open
    And cnc ChuckState becomes Open
    And cnc ChuckState should be Open
    Then machine state should be loading

Now the chuck is closed and all states are confirmed

    When robot CloseChuck becomes Active
    Then cnc CloseChuck should be Active
    And cnc ChuckState becomes Closed
    And cnc CloseChuck should be Complete
    And robot CloseChuck becomes Ready
    And cnc CloseChuck should be Ready

After the chuck is closed and the robot has retracted a safe distance, the robot requests the machine tool close the door

    When robot CloseDoor becomes Active
    Then cnc CloseDoor should be Active
    Then after 1.2 seconds cnc CloseDoor should be Complete
    And cnc DoorState should be Closed

The completes the material load and the machine tool cycle starts. Material load becomes not ready indicating the robot cannot load more material. The robot is still ready to load if asked to do so.

    When robot MaterialLoad becomes Complete
    And robot MaterialLoad becomes Ready
    Then machine state should be cycle_start
    And cnc MaterialLoad should be Not_Ready
    And robot MaterialLoad becomes Ready

Failure Scheario 1:

  Scenario: Cnc fails to start cycle
    Given robot MaterialLoad becomes Active

The following statement causes the execution data item to fail once it attempt to change.

    And simulate fail exec

This section creates the correct state of all the data items and then takes it through a single set of operations

    And Chuck is closed
    And Door is closed
    And robot MaterialLoad becomes Complete
    And robot MaterialLoad becomes Ready
    And cnc MaterialLoad should be Not_Ready

Make sure we are in the correct fault state when the load completes

    And machine state should be fault

Failure scenario 2:

The second failure scenario we will discuss is a failure to load a piece of material. This results in the machine tool entering into an idle state after acknowledging the failure of the material load. The scenario assert at the bottom that the machine state should be idle since the machine is ready to run, but the robot is not operational.

The final steps are the robot clearing the fault and becoming ready again. The machine tool enters re-enters the loading state since the material never arrived successfully. The material unload operation work in much the same way with the same recovery pattern.

  Scenario: Robot can't load material
    Given cnc MaterialLoad should be Active
    And robot MaterialLoad becomes Active
    And Chuck is closed
    And Door is closed

    When robot MaterialLoad becomes Fail
    Then cnc MaterialLoad should be Fail
    And material load state should be fail

    When robot MaterialLoad becomes Not_Ready
    And robot faults ACTUATOR with "Flame"
    And machine state should be idle

    When robot clears ACTUATOR
    And robot MaterialLoad becomes Ready
    And machine state should be loading

There are numerous additional scenarios that have been written for validation of the project. They can be found at:…/simulator/features

Enhancements to the MTConnect Standard

To implement a basic Robot to machine tool interface where we have one Robot loading one Machine Tool, the possible additions to the MTConnect standard are pretty minimal. The following data items were required on the machine tool side to represent the states of all components and the necessary interface events.

  1. ChuckState was added to the primary Rotary axis “C” with the values of OPEN, CLOSED, UNLATCHED and UNAVAILABLE.
  2. A top level device Interfaces component was added to hold all the interfaces.
  3. A MaterialLoader component was added as a child of the Interfaces component with the following data items:
    1. MATERIAL_LOAD with subtype REQUEST.
    2. MATERIAL_UNLOAD with subtype REQUEST.
    3. LINK_STATE that indicates if the interface is active with values ACTIVE , INACTIVE, or UNAVAILABLE.
  4. A ChuckInterface component was added as a child of the Interfaces component with the following data items:
    1. OPEN_CHUCK with subtype of RESPONSE.
    2. CLOSE_CHUCK with subtype of RESPONSE.
  5. A DoorInterface component was added as a child of the Interfaces component with the following data items:
    1. OPEN_DOOR with subtype of RESPONSE.
    2. CLOSE_CLOSE with subtype of RESPONSE.

The remainder of the machine tool components and data items are the standard composition of any standard Mazak implementation. The entire Devices.xml file is provided below. The sections in bold are the areas we have used to drive the state machine, the sections in bold italic are new to the standard.

  <?xml version='1.0' encoding='UTF-8'?>
  <MTConnectDevices xmlns:mt='' xmlns:xsi='' xmlns='' xsi:schemaLocation=''>
    <Header creationTime='2013-04-22T15:24:26Z' assetBufferSize='1024' sender='localhost' assetCount='0' version='1.2' instanceId='0' bufferSize='131072'/>
      <Device name='cnc' uuid='cnc' id='cnc_1'>
        <Description model='QTN' manufacturer='Mazak'>Mazak Quickturn - Mazak Quickturn for ROS/MTConnect</Description>
          <DataItem type='AVAILABILITY' category='EVENT' id='dtop_2' name='avail'/>
          <Axes name='base' id='base_3'>
              <DataItem type='ACTUATOR' category='CONDITION' id='base_4' name='servo_cond'/>
              <Linear name='X' id='X_5'>
                  <DataItem type='POSITION' category='SAMPLE' id='X_6' name='Xabs' subType='ACTUAL' units='MILLIMETER' nativeUnits='INCH' coordinateSystem='MACHINE'/>
                  <DataItem type='POSITION' category='CONDITION' id='X_7' name='Xtravel'/>
                  <DataItem type='LOAD' category='SAMPLE' id='X_8' name='Xload' units='PERCENT' nativeUnits='PERCENT'/>
                  <DataItem type='AXIS_FEEDRATE' category='SAMPLE' id='X_9' name='Xfrt' units='MILLIMETER/SECOND' nativeUnits='FOOT/MINUTE'/>
              <Linear name='Z' id='Z_10'>
                  <DataItem type='POSITION' category='SAMPLE' id='Z_11' name='Zabs' subType='ACTUAL' units='MILLIMETER' nativeUnits='INCH' coordinateSystem='MACHINE'/>
                  <DataItem type='POSITION' category='CONDITION' id='Z_12' name='Ztravel'/>
                  <DataItem type='LOAD' category='SAMPLE' id='Z_13' name='Zload' units='PERCENT' nativeUnits='PERCENT'/>
                  <DataItem type='AXIS_FEEDRATE' category='SAMPLE' id='Z_14' name='Zfrt' units='MILLIMETER/SECOND' nativeUnits='FOOT/MINUTE'/>
              <Rotary name='C' id='C_15'>
                  <!-- Rotary Part -->
                  <DataItem type='LOAD' category='SAMPLE' id='C_16' name='Cload' units='PERCENT' nativeUnits='PERCENT'/>
                  <DataItem type='ANGULAR_VELOCITY' category='SAMPLE' id='C_17' name='Cfrt' units='DEGREE/SECOND' nativeUnits='DEGREE/MINUTE'/>
                  <DataItem type='ANGLE' category='SAMPLE' id='C_18' name='Cdeg' subType='ACTUAL' units='DEGREE' nativeUnits='DEGREE'/>
                  <DataItem type='ANGLE' category='CONDITION' id='C_19' name='Ctravel'/>
                  <!-- Spindle part -->
                  <DataItem type='SPINDLE_SPEED' category='SAMPLE' id='C_20' name='Srpm' subType='ACTUAL' units='REVOLUTION/MINUTE' nativeUnits='REVOLUTION/MINUTE'/>
                  <DataItem type='LOAD' category='SAMPLE' id='C_21' name='Sload' units='PERCENT' nativeUnits='PERCENT'/>
                  <DataItem type='TEMPERATURE' category='SAMPLE' id='C_22' name='Stemp' units='CELSIUS' nativeUnits='CELSIUS'/>
                  <DataItem type='ROTARY_MODE' category='EVENT' id='C_23'>
                  <DataItem type='LOAD' category='CONDITION' id='C_24' name='Sload_cond'/>
                  <DataItem type='TEMPERATURE' category='CONDITION' id='C_25' name='Stemp_cond'/>
                  <DataItem type='CHUCK_STATE' category='EVENT' id='C_26' name='chuck_status'/>
              <Rotary name='C2' nativeName='S2' id='C2_27'>
                  <DataItem type='SPINDLE_SPEED' category='SAMPLE' id='C2_28' name='S2rpm' subType='ACTUAL' units='REVOLUTION/MINUTE' nativeUnits='REVOLUTION/MINUTE'/>
                  <DataItem type='LOAD' category='SAMPLE' id='C2_29' name='S2load' units='PERCENT' nativeUnits='PERCENT'/>
                  <DataItem type='TEMPERATURE' category='SAMPLE' id='C2_30' name='S2temp' units='CELSIUS' nativeUnits='CELSIUS'/>
                  <DataItem type='ROTARY_MODE' category='EVENT' id='C2_31'>
                  <DataItem type='LOAD' category='CONDITION' id='C2_32' name='S2load_cond'/>
                  <DataItem type='TEMPERATURE' category='CONDITION' id='C2_33' name='S2temp_cond'/>
          <Controller name='controller' id='controller_34'>
              <DataItem type='COMMUNICATIONS' category='CONDITION' id='controller_35' name='comms_cond'/>
              <DataItem type='LOGIC_PROGRAM' category='CONDITION' id='controller_36' name='logic_cond'/>
              <DataItem type='SYSTEM' category='CONDITION' id='controller_37' name='system_cond'/>
              <DataItem type='EMERGENCY_STOP' category='EVENT' id='controller_38' name='estop'/>
              <Path name='path' id='path_39'>
                  <DataItem type='SPINDLE_SPEED' category='SAMPLE' id='path_40' name='Sovr' subType='OVERRIDE' units='PERCENT' nativeUnits='PERCENT'/>
                  <DataItem type='PROGRAM' category='EVENT' id='path_41' name='program'/>
                  <DataItem type='PROGRAM' category='EVENT' id='path_42' name='subprogram' subType='x:SUB'/>
                  <DataItem type='LINE' category='EVENT' id='path_43' name='line'/>
                  <DataItem type='x:UNIT' category='EVENT' id='path_44' name='unitNum'/>
                  <DataItem type='x:SEQUENCE_NUMBER' category='EVENT' id='path_45' name='sequenceNum'/>
                  <DataItem type='PART_COUNT' category='EVENT' id='path_46' name='PartCountAct'/>
                  <DataItem type='PATH_FEEDRATE' category='SAMPLE' id='path_47' name='Fact' subType='ACTUAL' units='MILLIMETER/SECOND' nativeUnits='FOOT/MINUTE'/>
                  <DataItem type='PATH_FEEDRATE' category='EVENT' id='path_48' name='Frapidovr' subType='OVERRIDE' units='PERCENT' nativeUnits='PERCENT'/>
                  <DataItem type='PATH_FEEDRATE' category='EVENT' id='path_49' name='Fovr' subType='OVERRIDE' units='PERCENT' nativeUnits='PERCENT'/>
                  <DataItem type='TOOL_ID' category='EVENT' id='path_50' name='Tool_number'/>
                  <DataItem type='x:TOOL_GROUP' category='EVENT' id='path_51' name='Tool_group'/>
                  <DataItem type='x:TOOL_SUFFIX' category='EVENT' id='path_52' name='Tool_suffix'/>
                  <DataItem type='EXECUTION' category='EVENT' id='path_53' name='execution'/>
                  <DataItem type='CONTROLLER_MODE' category='EVENT' id='path_54' name='mode'/>
                  <DataItem type='x:COMMENT' category='EVENT' id='path_55' name='program_cmt'/>
                  <DataItem type='x:COMMENT' category='EVENT' id='path_56' name='subprogram_cmt' subType='x:SUB'/>
                  <DataItem type='x:DURATION' category='EVENT' id='path_57' name='auto_time' subType='x:AUTO'/>
                  <DataItem type='x:DURATION' category='EVENT' id='path_58' name='total_time' subType='x:TOTAL'/>
                  <DataItem type='x:DURATION' category='EVENT' id='path_59' name='cut_time' subType='x:CUT'/>
                  <DataItem type='MOTION_PROGRAM' category='CONDITION' id='path_60' name='motion_cond'/>
                  <DataItem type='SYSTEM' category='CONDITION' id='path_61' name='path_system'/>
                  <DataItem type='x:PALLET_NUM' category='EVENT' id='path_62' name='pallet_num'/>
          <Systems name='systems' id='systems_63'>
              <Electric name='electric' id='electric_64'>
                  <DataItem type='POWER_STATE' category='EVENT' id='electric_65' name='power'/>
                  <DataItem type='TEMPERATURE' category='CONDITION' id='electric_66' name='electric_temp'/>
              <Hydraulic name='hydraulic' id='hydraulic_67'>
                  <DataItem type='PRESSURE' category='CONDITION' id='hydraulic_68' name='hydra_cond'/>
              <Coolant name='coolant' id='coolant_69'>
                  <DataItem type='PRESSURE' category='CONDITION' id='coolant_70' name='coolant_pres'/>
                  <DataItem type='TEMPERATURE' category='CONDITION' id='coolant_71' name='coolant_temp'/>
                  <DataItem type='LEVEL' category='CONDITION' id='coolant_72' name='coolant_level'/>
              <Pneumatic name='pneumatic' id='pneumatic_73'>
                  <DataItem type='PRESSURE' category='CONDITION' id='pneumatic_74' name='pneu_cond'/>
          <Interfaces name='interfaces' id='interfaces_75'>
              <MaterialLoader name='material_loader' id='material_loader_76'>
                  <DataItem type='MATERIAL_LOAD' category='EVENT' id='material_loader_77' name='material_load' subType='REQUEST'/>
                  <DataItem type='MATERIAL_UNLOAD' category='EVENT' id='material_loader_78' name='material_unload' subType='REQUEST'/>
                  <DataItem type='LINK_STATE' category='EVENT' id='material_loader_79' name='robo_link'/>
              <ChuckInterface name='chuck_interface' id='chuck_interface_80'>
                  <DataItem type='OPEN_CHUCK' category='EVENT' id='chuck_interface_81' name='open_chuck' subType='RESPONSE'/>
                  <DataItem type='CLOSE_CHUCK' category='EVENT' id='chuck_interface_82' name='close_chuck' subType='RESPONSE'/>
              <DoorInterface name='door_interface' id='door_interface_83'>
                  <DataItem type='OPEN_DOOR' category='EVENT' id='door_interface_84' name='open_door' subType='RESPONSE'/>
                  <DataItem type='CLOSE_DOOR' category='EVENT' id='door_interface_85' name='close_door' subType='RESPONSE'/>
          <Door name='door' id='door_86'>
              <DataItem type='DOOR_STATE' category='EVENT' id='door_87' name='door_state'/>
          <Stock name="stock" id="stock">
              <DataItem category="EVENT" id="material" name="material" type="MATERIAL" />

Future Enhancements

The most significant future enhancement to the standard and the messaging semantics will be the addition of multiple devices and a many-to-many relationship between machine tools, CMMS, gauges, and multiple fixed or mobile robots. This can be achieved using an extension to the standard to allow for interface bindings.

We are proposing a lazy locking scheme where we provide a new data item within each interface that allows the devices to “pair” for the duration of the operation. For example, during the material load operation, the machine tool and the robot will each have a data item, for the sake of discussion, we can call it Binding that will have the following values: UNAVAILABLE, AVAILABLE, or <device-id>. If it is AVAILABLE then it can be bound to a device that is capable of fulfilling the request. Once bound it will change to the device Id of the associated device.

The mechanism will resolve disputes by allowing the requester to choose the responder from the available devices that are volunteering. So, if a machine tool wants material loaded and the cell has multiple Robots capable of loading material, multiple Robots may try to bind to the request, but only one will be accepted. The sequence will be as follows:

  1. Cnc 1 material loader binding AVAILABLE
  2. Cnc 1 material loader MaterialLoad ACTIVE
  3. Robot 1 material loader binding Cnc 1
  4. Robot 2 material loader binding Cnc 1
  5. Cnc 1 material loader binding Robot 2
  6. Robot 1 material loader binding AVAILABLE
  7. Robot 2 material loader MaterialLoad ACTIVE
  8. Robot 2 material loader MaterialLoad COMPLETE
  9. Cnc 1 material loader MaterialLoad READY
  10. Robot 2 material loader MaterialLoad READY
  11. Cnc 1 material loader binding AVAILABLE
  12. Robot 2 material loader binding AVAILABLE

In this way the robot and the CNC will coordinate the associations and the temporary bindings between devices. Having the requester make the selection is easiest way to resolve the possible locking issues between multiple devices and still have a complete read-only interface. The failure scenarios remain mainly the same with some bind timeout issues that will need to be resolved.

This is a very high level conceptual model and will require full design, architecture, and testing, the same as the previous interface went through. This same architecture should work with both mobile and stationary devices (though that will need to be explored as well.) The scheme borrows from optimistic locking mechanisms in databases and other technologies for distributed resource sharing.

Additional device models and interactions will also be required if devices other than CNC machine tools are involved in these extensions as well. This architecture will be well suited for an electronic manufacture floor with full automation and device monitoring as well as resource management.

Introducing the Vrtk Package

As part of my internship project here at System Insights, Chennai, I’ve been involved in developing an R-package called the ‘vrtk’, essentially a set of tools for reading and working with data from the vimana platform.

‘vrtk’ is short for ‘vimana Research ToolKit’ or ‘vimana R ToolKit’. It is intended to be an open-source set of the basic tools needed to read and work with data.

The library is very simple to use. Visit the github page for the download links, the source code, and to find the example files.

An Example

The rest of this post will be a simple demonstration — a rudimentary look at path-feedrate data from a generic machine tool.

The full example script can be found at this link, and it doubles as a tutorial. This post provides just a concise overview.

Installation and Loading:

Follow the instructions on the same github page to download and install the package. Next, open the example.R script, and follow along with the R-console.

The example file sets up a demo dataset, which has feedrate data and tool position data from a generic machine tool, monitored for around 30 minutes.

Reading the Data:

We use some of the core vrtk functions: createDeviceGroupfromGhetto, summary, getDevice, getData and merge to get the data into the right form.

Use the createDeviceGroupfromGhetto method to initialize a device group. Let’s call it devGrp.

devGrp <- createDeviceGroupfromGhetto("./402.json",data_folderpath="./402",createRData=TRUE)

Now, we can store the device itself in a variable.

dev <- getDevice(devGrp)

The vimana::summary function provides a quick summary of the information present.


The summary tells us that the json is associated with a total of 1 device, with 11 DataItems associated.

A DataItem is vrtk’s representation of the type of data measured. Examples — Xload, Yload, Zload, path_feedrate, Xact etc.

The vimana::merge function merges the DataItems we want, and reads them into a dataframe with the appropriate timestamps.

For this example, we want the pathfeedrate data and the position data. So we use merge as follows:

allDataFrame <- merge(dev,"FEEDRATE-ACTUAL|POS")

After some column-renaming, the data is in a data.frame and ready for use. We can plot the pathfeedrate data with the following command. The resultant plot is shown below.



The Example Analysis

For now, we’ll simply compute a feedrate from the position data and see how and when it differs from the pathFeedrate data from the same machine during the same duration.

First, we need the distance travelled based on the given position data. Here is a small function to compute it:

dist <- function(xVec,yVec,zVec) { 
  # Euclidean dist
  xDiff = diff(xVec)
  yDiff = diff(yVec)
  zDiff = diff(zVec)
  return(c(NA,sqrt(xDiff^2 + yDiff^2 + zDiff^2)))
allDataFrame$prev.dist <- dist(allDataFrame$xPos,allDataFrame$yPos,allDataFrame$zPos)

Now we just need to compute the distances, and divide by the time difference to get the computed feedrate:

timeDifsVector <- c(NA,diff(allDataFrame$timestamp))
allDataFrame$computed.path.feedrate <- allDataFrame$prev.dist/timeDifsVector

Now, compute the Pearson correlation coefficient between the reported PathFeedrate and the calculated PathFeedrate from the position data:


This yields a value of ~0.78, which is decent but not as high as expected. What would account for the difference, though?

Let’s conclude this example by looking at the difference between the reported and computed feedrates. While the difference does not mean anything in physical terms, it provides a clear picture of where the reported feedrate is differing from the computed one.

difference <- allDataFrame$reported.path.feedrate - allDataFrame$computed.path.feedrate


The difference seems to spike deterministically. We surmise that the spikes correspond to tool changes. This can actually be checked — we just need to check the toolID data, if its available.

For now, we’ll conclude this example by taking a much smaller sampling period, where there aren’t any spikes, and check the correlation.

sample.reported <- allDataFrame$reported.path.feedrate[675:740]
sample.computed <- allDataFrame$computed.path.feedrate[675:740]


97% in the regions between spikes — not too shabby!

We see several interesting things happening here: * In regions between spikes, the reported and computed feedrates correlate well. * While the reported feedrate maintains a particular plateau value for a while, the computed feedrate shows minor fluctuations. Interestingly, using the same position data as in this example, it is possible to see that feedrate fluctuates (usually, the reported is higher), just before the tool takes a sharp turn. * Also, when there’s a change in the plateau value, the computed feedrate always lags for a datapoint or two before reaching the reported value, as one would expect from a real world machine.

That’s about it, I suppose! This concludes our trivial example using the vrtk package. Be sure to check out the github page and the documentation for further details and the source-code.

We Are Hiring!

At System Insights, we build vimana, the world’s most advanced platform for manufacturing data analytics. We are a small, fast-growing company with 15 employees globally and we are looking to grow our R&D center in Chennai, India. We are currently hiring for the following positions in Chennai:

Manufacturing Engineer

You will be responsible for leading the deployment of vimana at customer facilities around the world, and working with our users to deliver vimana’s value.

  • B.E/B.Tech from reputed a college/university, preferably in Mechanical Engineering (or equivalent) with strong academics
  • 2~3 Years experience
  • Hands-on shopfloor experience with Production/Process Engineering, New Product Development, Industrial Engineering, Manufacturing Systems
  • Experience/familiarity with Value Stream Mapping, 6 Sigma, TPM etc., a plus
  • Excellent communication skills

SW Developer

You will be responsible for developing the cutting-edge software technologies that power vimana. You will be working closely with our development team based in Berkeley, California.

  • Strong experience in Ruby, AJAX, Java Script, HTML/CSS (at least 2 years)
  • Experience with Web 2.0 development, Object Oriented Design and MVC Frameworks
  • Experience with SQL and noSQL technologies
  • Knowledge of HTML5, Git
  • Experience in using testing frameworks and unit tests
  • Excellent communication skills

Dev-Ops Lead

You will be responsible for monitoring, managing, and maintaining the vimana platform for SaaS and on-site deployments. You will be responsible for building and growing a team of System Administrators and DevOps Engineers to maintain the vimana platform. You will be working closely with our development team based in Berkeley, California.

  • Strong experience in deploying, configuring and managing applications using Amazon AWS (EC2, S3, RDS, EMR …)
  • Skills in mongodb and SQL: Replication, sharding, tuning
  • Experience with Chef or other configuration management tool
  • Basic understanding of network topologies and configuration (routing, subnets, NAT).
  • Experience in application monitoring and log file management for multi-function, multi-tenant applications
  • System administration skills for Linux (Ubuntu, Centos) and Windows
  • Lead and work with a 24x7 distributed global team

R&D Engineer

You will join our R&D team to develop next-generation technology for manufacturing data analytics, this includes: data analytics, software development, and hardware engineering.

  • Fresher/recent graduate with strong academics
  • Experience with technical programming languages like Matlab or R
  • Good project experience
  • Excellent communication skills

If you are interested, please fill out this application (don’t forget to attach your resume!).