# Not All Equipment Data is Equal

**URL:** <https://community.criticalmanufacturing.com/t/not-all-equipment-data-is-equal/878>\
**Category:** Blog\
**Tags:** medical-devices, v11.3, equipment\
**Created:** [September 29, 2026, 8:34am UTC](https://community.criticalmanufacturing.com/t/not-all-equipment-data-is-equal/878 "2026-09-29T08:34:36Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rodrigo\_Cordeiro](https://yyz2.discourse-cdn.com/flex050/user_avatar/community.criticalmanufacturing.com/rodrigo_cordeiro/32/1304_2.png) [@Rodrigo\_Cordeiro](https://community.criticalmanufacturing.com/u/Rodrigo_Cordeiro)\
**Post date:** [September 29, 2026, 8:34am UTC](https://community.criticalmanufacturing.com/t/not-all-equipment-data-is-equal/878/1 "2026-09-29T08:34:36Z")

</div>

## **Introduction**

Connected equipment can provide a rich set of manufacturing information beyond simple production outcomes. During normal operation, it continuously generates data that describes both the **state** of the equipment and the **execution** of the process, including equipment status, process parameters, recipe details, alarms, state transitions, cycle times, production counts, material tracking events, operator interactions and other operational and process-related information.

The integration challenge is not only how to acquire this information, but also how to determine which data is valuable, where it should be routed and how it can be used to support manufacturing decisions. Different types of data serve different business and operational purposes and therefore may have different destinations within the manufacturing ecosystem. Understanding these objectives is a key factor in designing an effective MES integration strategy.

In general, equipment data is collected for three primary purposes:

- MES operations and production **execution**
- **Quality** , traceability and exception management
- Reporting and advanced **analytics**

### **MES Operations and Production Execution**

Equipment provides operational information that enables the MES to maintain an accurate representation of what is happening on the shop floor, supporting material tracking, resource management, production monitoring, equipment status management and other core manufacturing execution functions.

This is the primary objective in many equipment integration projects: ensuring that manufacturing activities are accurately reflected in the MES so that production can be managed and monitored effectively.

Equally important is the reverse flow of information, where the MES provides equipment with the manufacturing context required for execution, including production orders, material information, recipes, process parameters and work instructions. Together, these bidirectional information flows enable coordinated and controlled manufacturing execution.

### **Quality, Traceability and Exception Management**

In CM MES, a _Data Collection_ provides a structured way to acquire data from equipment and define how the collected parameters relate to a manufacturing operation. During execution, a Data Collection Instance records the collected values within their production context. Depending on the configuration, data collection can be associated with events such as _Track-In_ or _Track-Out_ or performed as an _Immediate Data Collection_ during processing. The resulting readings can be related to the material, resource or sample. Collected values can trigger an exception workflow or perform actions like placing a material on hold. This context makes a measurement useful as manufacturing evidence, rather than just a value with a timestamp.

This contextualization supports:

- Process monitoring and control
- Quality verification and compliance
- Electronic Device History Record (eDHR) completeness
- Statistical Process Control (SPC)
- Traceability and genealogy
- Exception handling and non-conformance management

### **Reporting and Advanced Analytics**

The **Data Platform** serves a distinct purpose: bringing together operational and process data for reporting, trend analysis, statistical analysis, engineering investigations, and data mining. Unlike individual MES transactions, this broader analytical scope is designed to surface patterns and insights that only emerge when looking at data over extended periods or across multiple production scenarios.

The MES uses **IoT Event Definitions** to collect data in a structured and consistent way — each definition acts as a typed schema that determines what data is captured, how it is organized, and in what manufacturing context it is recorded. Depending on the type of equipment data to be collected, several built-in IoT Event Definitions are available out of the box, each optimized for a specific data collection scenario:

* * *

**[Post Telemetry](https://developer.criticalmanufacturing.com/11.1/reference/api-data-platform/docs/index.html#operation-receive-PostTelemetry)** provides a mechanism for publishing equipment data to the CM MES IoT Data Platform. It captures continuous, time-series streaming data from equipment or sensors — ideal for real-time process monitoring of variables such as temperature, pressure, speed, and similar operational parameters.

Each telemetry event carries two main groups of fields:

- **Parameters** — the actual data payload, including parameter name, class, one or more timestamps, numeric and string values, and unit of measure.
- **Tags** — free-form key/value pairs for enriching the event with additional metadata.

To make analysis meaningful, events also include **manufacturing context** fields that identify where and under what conditions the data was collected: Enterprise, Site, Facility, Area, Resource, Flow, Step, Material, and Product.

* * *

**[Post Measurement](https://developer.criticalmanufacturing.com/11.1/reference/api-data-platform/docs/index.html#operation-receive-PostMeasurement)**, on the other hand, is the right choice when capturing discrete, named measurement results, typically quality or inspection data tied to a specific material being processed under a given recipe. Rather than continuous streams, it focuses on structured, point-in-time results that are directly linked to production context.

Each measurement event carries:

- **Measurement\_Name** — identifies the specific measurement being reported.
- **Parameters / Values** — the measurement data as string-based key/value pairs.
- **Manufacturing context** — Enterprise, Site, Facility, Area, Resource, and Material, with the addition of **Recipe** — anchoring the result to the exact process recipe under which the material was being processed.

* * *

[Post Data Collection](https://developer.criticalmanufacturing.com/11.1/reference/api-data-platform/docs/index.html#operation-receive-PostDataCollection) positioned as the richer traceability alternative when full MES execution context is needed. The field groups are:

- **Header** – event correlation and audit metadata
- **Data Collection details** – execution identity, mode, operators, and timestamps
- **Parameter readings** – the actual collected values with instrument and unit context
- **Manufacturing context** – deep resource, flow, step, and material lineage (including parent material and sub-materials)

* * *

[Resource Alarm](https://developer.criticalmanufacturing.com/11.1/reference/api-data-platform/docs/index.html#operation-receive-ResourceAlarm) is framed around equipment health and reliability analytics. Its field groups are:

- **Header** – same consistent traceability structure as Post Data Collection
- **Action and Timestamp** – alarm lifecycle tracking
- **Alarm details** – Code, Type, Severity, Description, Cause
- **Resource context** – Resource and SubResource identification
- **Manufacturing location** – Enterprise → Area hierarchy for cross-site benchmarking

* * *

For scenarios requiring more complex contextualization, **[Custom IoT Event Definitions](https://help.criticalmanufacturing.com/11.3/userguide/data-platform/events/iot-event-definition/create_iot_event_definition/)** offer the flexibility to model and capture data beyond what the standard event types provide.

With a fully configurable property schema, they support a wide range of data types and **IoT Schema** for nested property structures — as well as Mandatory and Indexed property flags for validation and queryability.

* * *

Together, this data can support:

- Dashboards
- Reporting
- Statistical analysis
- Predictive analytics
- Data mining

### **The Right Destination for Data**

The key design question is therefore not simply “Where can this signal be sent?” but “What decision does it need to support and what context and lifecycle should be preserved with it?”.

 ![equipment data](https://canada1.discourse-cdn.com/flex050/uploads/community_criticalmanufacturing/original/2X/8/888266381af086f000329f3a03a22bd17a89382c.jpeg)

## **Use Case**

A simple equipment integration scenario helps illustrate the distinction in practice. It looks at pressure and speed data acquired through Connect IoT and recorded in the relevant MES Data Collection for a material at the start and end of production. At the same time, the full variation in these parameters can be streamed to a centralized Data Platform for broader analysis.

### **Prepare Equipment**

To provide the equipment with the correct operational context, the **material name** , **production order** and **recipe** are transferred to it before execution begins.

To implement this behavior, a Business Rule (or DEE Action) attached to the material tracking event ( **MaterialManagement.MaterialManagementOrchestration.ComplexTrackInMaterials.Post** ) sends a request containing the production order and material information to the workflow. It then uses the MES Service **UploadRecipesToResources** orchestration to upload the recipe to the equipment.

The following code snippet illustrates the main steps of the DEE:

```csharp

// Read the input context and make sure this is a TrackIn action.
var serviceProvider = Input["ServiceProvider"] as IServiceProvider;
var actionGroupName = Input["ActionGroupName"]?.ToString() ?? "";
var isTrackIn = actionGroupName.Contains("TrackIn", StringComparison.OrdinalIgnoreCase);

if (!isTrackIn)
    return;

// Load the material that is starting production and resolve the resource that will execute it.
var trackInInput = Input["ComplexTrackInMaterialsInput"] as ComplexTrackInMaterialsInput;

// Load the Material and get the resource
var material = trackInInput.Materials.FirstOrDefault();
material.Load();
var resource = material.LastProcessedResource;

// Get the orchestration services that know how to manage the recipe-resource association.
var orchestration = serviceProvider.GetService<IResourceOrchestration>();
var entityFactory = serviceProvider.GetService<IEntityFactory>();

// Read the active recipe assigned to the material for this production step.
var recipeName = (material.CurrentRecipeInstance?.ParentEntity as IRecipe)?.Name ?? "";
if (string.IsNullOrEmpty(recipeName))
    return;

var recipe = entityFactory.Create<IRecipe>();
recipe.Name = recipeName;
recipe.Load();

// Send Order Name and material to the equipment

// Controller instance 
IAutomationControllerInstance controllerInstance = resource.GetAutomationControllerInstance();
if (controllerInstance == null)
{
    throw new Exception("No automation controller instance found for the resource.");
}

// Production Order
string ordername = material.ProductionOrder?.Name ?? string.Empty;

var payload = new
{
    order = ordername ?? string.Empty,
    material = material.Name
};

string json = JsonConvert.SerializeObject(payload);

controllerInstance.SendRequest("ON_PREPAREEQUIPMENT", json, 10000);

// Request the resource recipe information so the current recipe can be uploaded to the equipment.
var recipeResourceInput = new LoadResourceRecipesFromResourceInput 
{
    Resource = resource,
    LevelsToLoad = 1
};

var resourceWithRecipes = orchestration.LoadResourceRecipesFromResource(recipeResourceInput).Resource;
var recipeResource = resourceWithRecipes.ResourceRecipes
    .FirstOrDefault(rr => rr.Recipe.Name == recipeName);

if (recipeResource == null)
    return;

// Build the recipe collection and upload it through the MES orchestration layer.
var recipeCollection = entityFactory.CreateCollection<IRecipeResourceCollection>();
recipeCollection.Add(recipeResource);

var recipesToUpload = new Dictionary<IResource, IRecipeResourceCollection>
{
    { resourceWithRecipes, recipeCollection }
};

resourceWithRecipes.UploadRecipesToResources(recipesToUpload, null);

```

> To avoid unnecessary execution, the DEEs should verify (_Test Condition Code_) that the **ResourceAutomationMode** is set to **Online** before executing the logic.

The workflow uses a _System Action Listener_ to receive the request and a _Recipe Upload Request_ task to upload the recipe to the equipment.

 ![PREPARE_EQUIPMENT](https://canada1.discourse-cdn.com/flex050/uploads/community_criticalmanufacturing/original/2X/8/8ddf0f8b43d16d6fe7b2a4324db11b5db0db1850.png)

### **Read Equipment Data**

Equipment data should be acquired during both **Track-In** and **Track-Out** events, as mentioned previously:

- `MaterialManagement.MaterialManagementOrchestration.ComplexTrackOutMaterials.Pre`
- `MaterialManagement.MaterialManagementOrchestration.ComplexTrackInMaterials.Post`

The DEE analyzes the open Data Collection associated with the material and requests the corresponding values from the equipment. Data Collection parameters are matched to equipment properties based on their names, allowing the DEE to automatically retrieve the required values.

> For more complex scenarios, a Smart Table can be used to translate between Data Collection parameters and equipment properties.

The **Sample Name** determines which parameters should be collected at each stage of the process, distinguishing between **Track-In** and **Track-Out** data collection.

 ![DATA_COLLECTION](https://canada1.discourse-cdn.com/flex050/uploads/community_criticalmanufacturing/original/2X/d/d1a94ab66f5e87a83e3430fd025b75131cb50ed9.png)

The following snippet illustrates the key steps performed by the DEE:

```csharp
// Identify the current sample and the material being processed.
var sampleId = actionGroupName.Contains("TrackIn", StringComparison.OrdinalIgnoreCase)
    ? "TrackIn"
    : "TrackOut";
var material = GetMaterialForAction(Input, actionGroupName);
var dcInstance = GetOpenDataCollectionInstance(material);
var parameters = GetParametersForSample(dcInstance, sampleId);
var resource = material.LastProcessedResource;

// Build the requested topics with null values; for example:
// [{ "parameterName": "Pressure", "value": null }, { "parameterName": "Speed", "value": null }]
var topicEntries = parameters
    .Select(p => new { parameterName = p.Name, value = (string)null })
    .Distinct()
    .ToList();

// Serialize the topic list and ask the equipment for the requested values.
var payload = JsonConvert.SerializeObject(topicEntries);
var response = resource.GetAutomationControllerInstance().SendRequest("ON_GETTOPICS", payload, 10000);
var values = ParseResponse(response);

// For each returned value, find the matching Data Collection parameter and post it.
foreach (var item in values)
{
    var parameter = parameters.First(p =>
        p.Name == item.parameterName &&
        p.SampleName == sampleId);

    // Create the Data Collection point with the correct context and typed value.
    var point = new DataCollectionPoint
    {
        SourceEntity = dcInstance,
        TargetEntity = parameter,
        SampleId = sampleId,
        ReadingName = parameter.ReadingName,
        ReadingNumber = parameter.ReadingNumber,
        Value = ConvertValue(item.value, parameter.DataType)
    };

    // Post the value to the correct MES Data Collection instance.
    dcInstanceOrchestration.PostDataCollectionPoints(new PostDataCollectionPointsInput
    {
        DataCollectionInstance = dcInstance,
        DataCollectionPoints = new DataCollectionPointCollection { point }
    });
}

```

The workflow reads the requested equipment properties and returns their values as a JSON list.

 ![GET_TOPICS_WORKFLOW](https://canada1.discourse-cdn.com/flex050/uploads/community_criticalmanufacturing/original/2X/1/14b41fce1490c3865745b1d0b8d602132ca08c68.png)

The Code Task does the required interpretation and transformation:

```typescript
public async main(inputs: any, outputs: any): Promise<any> {
    const topics: { parameterName: string; value: any }[] = inputs.data;

    const topicNames: string[] = topics.map(t => t.parameterName);

    const allProperties = Array.from<any>(
        this.framework.driver.automationControllerDriverDefinition
            .AutomationDriverDefinition.Properties
    );

    const properties = allProperties.filter(property => topicNames.includes(property.Name));

    if (properties.length === 0) {
        const requestedNames = topicNames.join(", ");
        throw Error(`No Property with Names [${requestedNames}] were found in the AutomationDriverDefinition`);
    }

    const values = await this.framework.driver.getProperties(properties);

    const valuesMap: Record<string, any> = {};
    for (const automationProperty of values) {
        const { propertyName, value } = automationProperty;
        const extractedValue = value !== null && typeof value === 'object' && !Array.isArray(value)
            ? value.value ?? null
            : value;
        valuesMap[propertyName] = extractedValue;
        this.framework.logger.info(`${propertyName} : ${extractedValue}`);
    }

    const result = topics.map(t => ({
        parameterName: t.parameterName,
        value: valuesMap[t.parameterName] ?? null
    }));

    outputs.rawData.emit(JSON.stringify(result));
}

```

### **Send Data to the Data Platform**

Equipment data can be forwarded to the Data Platform by using a DEE to toggle a persistent flag indicating whether a material is currently in production. The integration logic can then use this flag to determine when telemetry data should be collected and published. This way we are focusing our data collection for a time window where there are materials being processed.

The material production state can change through the following action groups:

- MaterialManagement.MaterialManagementOrchestration. **AbortMaterialsProcess**.Post
- MaterialManagement.MaterialManagementOrchestration. **TerminateMaterialsProcess**.Post
- MaterialManagement.MaterialManagementOrchestration. **TerminateMaterial**.Post
- MaterialManagement.MaterialManagementOrchestration. **ComplexTrackInMaterials**.Post
- MaterialManagement.MaterialManagementOrchestration. **ComplexTrackOutMaterials**.Pre

When a material enters production (_Track In_), the DEE can enable data collection by setting the persistent flag. When the material leaves production, is terminated or is aborted, the DEE can disable data collection by clearing the flag.

The following example illustrates how the production-state flag is managed and how equipment telemetry values are published to the Data Platform.

 ![SET_TOGGLEPOSTEVENT](https://canada1.discourse-cdn.com/flex050/uploads/community_criticalmanufacturing/original/2X/9/96bcc8e7ec8d6ac7274c4f70aa68304bd613f20d.png)

When the pressure changes, the equipment triggers an event and sends the reading as telemetry to the Data Platform:

 ![SET_POSTTELEMETRY_PRESSURE](https://canada1.discourse-cdn.com/flex050/uploads/community_criticalmanufacturing/original/2X/a/a06b5a4021a98fa7979232021fd0c1a6dca65f8a.png)

When the speed changes, the equipment triggers an event and sends the reading as telemetry to the Data Platform:

 ![SET_POSTTELEMETRY_SPEED](https://canada1.discourse-cdn.com/flex050/uploads/community_criticalmanufacturing/original/2X/4/43580eb26a39f4cc12834ceeadc5d08c494b6a9a.png)

## **Explore Data**

Once collected, equipment data can be analyzed over time, included in reports and displayed on dashboards. For example, the dashboard below brings pressure and speed readings together so engineers can compare how they vary during production and investigate unusual patterns. The same telemetry can support longer-term trends and comparisons across equipment or materials, while the MES Data Collection retains the readings needed as evidence for each manufacturing operation.

 ![Dashboard](https://canada1.discourse-cdn.com/flex050/uploads/community_criticalmanufacturing/original/2X/e/e75f519244a790869e17c0bbb94ee5b6536efdd7.png)

## **Conclusion**

The value of equipment data depends on the decision it supports. MES Data Collection preserves measurements in the context of execution, quality and traceability; the Data Platform makes broader telemetry available for analysis and reporting. By choosing the right destination for each signal, an integration can support immediate production decisions and reveal patterns that become clear only over time.