Bufferstack.IO®

As software engineers, we often dive into solving problems headfirst, eager to write code and see results. But a recent experience reminded me of the importance of following a proper engineering approach—especially when dealing with complex standards like MTConnect. Here’s a blog post about how we resolved a tricky issue, the time we wasted by taking the wrong path, and the lessons I’ll carry forward.

While working on an MTConnect-to-OPC UA adapter, we encountered an issue with a DataItem called cvars. This DataItem, defined as an EVENT of type VARIABLE, was supposed to display a set of key-value pairs (e.g., "100: 55.2; 101: 11; 103: ON; ..."). However, our code kept falling back to "UNAVAILABLE", even when the data was present in the /current response. The XML structure used VariableDataSet with Entry elements, but our parsing logic wasn’t handling it correctly.

Initially, we took a reverse approach:

• Jumped to Implementation: We started by analyzing the /current response and tweaking the code to parse the VariableDataSet structure, assuming it was a table-like DataItem.
• Resorted to Hardcoding: When the logic didn’t work, we hardcoded cvars to be treated as a TABLE DataItem, which temporarily fixed the issue but wasn’t scalable or standards-compliant.
• Wasted Time on Trial-and-Error: We spent hours debugging, tweaking, and testing, only to realize we were missing a fundamental understanding of the MTConnect standard.

This approach led to frustration, wasted time, and a brittle solution that wouldn’t hold up for other DataItems using VariableDataSet.

The breakthrough came when we stepped back and followed a proper engineering approach, as any seasoned engineer should:

1. Document Analysis
   We consulted the MTConnect standard (ANSI/MTC1.5-2020) and analyzed the definition of VariableDataSet. We learned that:

• VariableDataSet is used for EVENT DataItems of type VARIABLE to represent key-value pairs.
• It can contain Entry elements or a simple value (e.g., "UNAVAILABLE").
• Entries with removed="true" should be excluded.

1. System Analysis
   We compared the standard to our implementation:

• The /probe response defined cvars as an EVENT DataItem with type="VARIABLE" and representation="VALUE", not TABLE.
• Our code wasn’t handling the variability of VariableDataSet (e.g., switching between Entry elements and "UNAVAILABLE").
• We needed a dedicated parsing logic for VariableDataSet.

1. System Design
   We designed a solution that aligned with the standard:

• Added a parseVariableDataSet function to handle the VariableDataSet structure, filtering out removed="true" entries and formatting the data into a string.
• Updated the updateDataItem function to use this logic for EVENT DataItems of type VARIABLE.
• Ensured the solution was general, avoiding hardcoding for cvars.

1. Implementation and Validation
   We implemented the solution, tested it with real data, and validated it using an OPC UA client. The result? cvars now correctly showed "100: 55.2; 101: 11; 103: ON; 104: 18; 105: 151; 106: #3" when data was present, and "UNAVAILABLE" when appropriate.

By following this structured approach, we resolved the issue in a way that was:

• Standards-Driven: Aligned with the MTConnect standard, ensuring correctness.
• Scalable: General enough to handle other DataItems using VariableDataSet.
• Maintainable: No hardcoding, with detailed logging for future debugging.

This experience taught me a valuable lesson about the right way to tackle software design challenges:

1. Start with Documentation
   Always begin by thoroughly reading the relevant standards, specifications, or documentation. For us, this meant diving into the MTConnect standard to understand VariableDataSet before writing a single line of code.
2. Analyze Before Designing
   Compare the standard to your system to identify gaps. Understand the problem domain fully before jumping to solutions.
3. Design with Scalability in Mind
   Avoid quick fixes like hardcoding. Design solutions that are general, robust, and aligned with the standard, so they can handle future cases.
4. Implement and Test Thoroughly
   Build with detailed logging to aid debugging, and test with real data to catch edge cases early.
5. Document and Iterate
   Document your solution and reasoning for future reference, and be ready to iterate if new issues arise.

By initially skipping the documentation and analysis steps, we wasted hours on trial-and-error, produced a temporary fix that didn’t scale, and delayed the real solution. Following the proper path—documents, analysis, and then system design—saved us from further headaches and resulted in a much better outcome.

As engineers, it’s tempting to dive into coding right away, but taking the time to understand the problem domain first is always worth it. The next time you face a complex issue, remember: documents, analysis, and then system design. It’s the path to robust, maintainable software—and it saves you from the frustration of going in circles.

Get the Bufferstack.IO OPCUA MTConnect Adapter Shareware installer from this link – https://github.com/hj91/MTConnect-OPCUA-Server-Installer