Distributed Test Manager (DTM)

The Distributed Test Manager (DTM) is a Windows™ application which enables many different types of system level testing by simulating multiple devices in a system. DTM is a system level simulator that is unique compared to other Triangle MicroWorks tools which test the communications of a single device. DTM is a highly extensible tool with multiple options for configuring devices, creating test cases, and simulating data in the system.


Substation Communication Testing

Use Case

 


Substation automation has increased the complexity of communications in substations. Part of this complexity arises from IEC 61850 which has introduced many new communication paths with GOOSE, Sampled Values, and MMS based messages that flow between different equipment in the substation. Implementing IEC 61850 on the process bus is moving hard-wired connections to network based messaging which requires a new form of verification versus traditional substations. This new virtual wiring can be verified by simulating the communications of different components in the system together and checking that the right messages are being transmitted and received throughout the system. Testing the communication configuration of the system early in the design process can help reduce risk during the deployment phase.

DTM Capabilities

  • Simulate the communications and data model for each Client, Server, Publisher, or Subscriber in a substation
  • Load IED configurations based on SCL Files (IEC 61850), DNP3 XML Device Profiles, or point lists
  • Import an entire IEC 61850 substation configuration based on SCD File
  • Simulated IEC 61850 Clients subscribe to Control Blocks (Reports, Logs, GOOSE) or issue commands to Servers
  • Simulated IEC 61850 Servers publish and subscribe GOOSE messages
  • Simulated DNP3 or IEC 60870-5 Masters can read, poll, or request reports from Outstations
  • Simulate gateways and protocol translators with scripting and simulated data devices




Example:  Simulating an IEC 61850 Substation

This example shows a simulation of multiple bay controllers, protection devices, and an HMI in an IEC 61850 based automated substation.  The station bus has MMS based Client/Server connections with Reports, Controls, and Logs. The process bus has broadcast GOOSE messages and Sampled Values streams which are subscribed to by different components.  The Object Models, Data Sets, Control Blocks, and subscription configurations need to be verified to ensure that the right information is available to different devices across the substation. 

61850 Substation Use Case


DTM is simulating the communications and Object Models of the Bay Controllers and protection IEDs. The simulation can be run on a single PC or distributed across multiple hosts to test the communication configuration of the substation with a real station bus and process bus.  IED configurations are loaded from SCL files (.ICD or .SCD) including the Object Models, services, and communications. The HMI is a simulated IEC 61850 Client which subscribes to Control Blocks in the IEDs and issues controls to the IEDs.

Test cases can be built on top of these simulated devices to test specific substation automation processes.  In this example, GOOSE message publishing and subscribing configurations are tested by generating specific data changes which test GOOSE signals all the way through the Publisher's Object Model, Data Set, and Control Block to the Subscriber's External Reference. Also in this example, the IEC 61850 Client is testing the Report Control Blocks that are configured in the IEDs.

IED behavior can be modeled with scripting capability in DTM which is highly configurable. Variables in scripts can be driven by the transition of specific Data Attributes in the Object Model. Scripts can also directly set Data Attributes in the Object Model. GOOSE publishing and subscribing can tie directly into scripting functions based on configuration of Control Blocks and Data Sets in SCL Files. In this way, scripts can be created to monitor and verify entire data paths in the system. Data changes can be driven by playing back captured CSV files from real systems.  Data change time steps can be configured to a specific number of seconds or follow the captured time steps from the CSV file.




 
© 2013 Triangle MicroWorks, Inc. All rights reserved.