Managers rely on compliance reports to prove that their operations are meeting their regulatory obligations. These reports are typically made up from multiple data sources, such as SCADA historian data and laboratory test results, which are compared with the requirements of the regulations to demonstrate compliance.
In the control system space where Neo Consulting operates, we have found that historian data is obtained from field instruments via a data path that typically consists of multiple control system devices, all of which can introduce errors. Therefore, over time it is possible that this regulatory compliance data loses its validation for quality and accuracy. When the path that data takes is not validated, it is not possible to be sure that the resultant compliance reports depict an accurate and true representation of what is occurring in the field.
As a manager or officer responsible for regulatory compliance, can you demonstrate that the path your compliance data follows has been designed; validated; is secure; and management of any changes is controlled?
What risks arise from not validating data paths?
Generally, data paths are initially configured and commissioned appropriately and the data validated. However, over time as software is modified and instrument and control systems are maintained or replaced, issues can arise in data paths. Some of the key risks include:
a) Sensing element measurement drift – If periodic maintenance and calibration is not performed on compliance instruments their measured value may drift from the true value.
b) Scaling and unit mismatches – If two devices that communicate directly with each other are set up with inconsistent scales or units, data transferred between the devices will be
c) Data location or datatype mismatches – If two devices that communicate directly with each other are set up to transfer data from an incorrect memory location or to store data incorrectly, the data ultimately displayed will be incorrect.
These risks will all fundamentally affect the quality of the historian compliance data being collected.
How can these risks be mitigated?
Compliance data path risks can be avoided by the adoption of a formal process that requires the path be consciously engineered, documented and safeguarded. The following three stages are Neo’s recommendations on how this can be achieved:
1. Design the data path by implementing, commissioning and documenting a data custody chain
Compliance data path issues can be avoided by designing and testing data custody chains. These custody chains involve documenting how data will be stored and transmitted between each device for each data path. An example data custody chain is depicted in Figure 1. Through the calibration verification process, this can be tested to provide end to end confidence.
Figure 1: An example data custody chain document
2. Secure the devices and software involved in the data path
Following the design and implementation of the data custody chain, the devices and software on the data path need to be secured to prevent unauthorised modifications. This can be achieved by considering physical security, software security and human factors.
3. Control changes to the data path
Change management relates to people, process and technology. It is necessary to consider all of these factors when undertaking change management. In particular, a thorough process is critical to ensure that changes are carried out correctly and verified.
Ensuring that these steps are formalised and that compliance data paths are audited on a regular basis will allow you to be confident that the reports you sign off and submit are based on reality.
If you would like to talk further on how Neo Consulting can assist with ensuring your compliance data is valid please get in touch.
Jonathan Cuff
Electrical Engineer
d: +64 9 365 9737 | t: +64 9 365 9720 | m: +64 27 535 1718 | e: jonathan.cuff@neo.co.nz
