Set debugging level
-c [ –config ] Config path
-r [ –raw ] Show raw telegram data
-f [ –frame ] Show frame data
-R [ –readyfile ] Ready notification file
```# 29.2 IEC 60870-5-103
### IEC 60870-5-103
The IEC 60870-5-103 protocol is a companion standard for the informative interface of protection equipment. Standard IEC 60870-5-103 was prepared by IEC technical committee 57 (Power system control and associated communications).It is a companion standard for the basic standards in series IEC 60870-5:
Standard IEC 60870-5-103 defines communication between protection equipment and devices of a control system (supervisor or RTU) in a substation.
Standard IEC 60870-5-103 defines a multipoint communication protocol via which information can be exchanged between a control system (supervisor or RTU) and one or more protection devices. The control system is the master and the protection devices are the slaves. Each slave is identified by a unique address between 1 and 254. Address 255 is reserved for broadcast frames.
### IEC 60870-5-103 Master
### Configuring datapoints
WCC Lite supports IEC 60870-5-103 Master protocol over serial link (according EIA RS-485). Its full functionality list can be found in a IEC 60870-5-103 PID Interoperability List.
To use IEC 60870-5-103 Master in WCC Lite, it has to configured via an Excel configuration. This configuration contains two Excel sheets where parameters have to be filled in - Devices and Signals.
##### IEC 60870-5-103 parameters for Devices tab
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range
|
| Min | Max |
| name
| string | User-friendly name for a device
| Yes | | | |
| description
| string | Description of a device
| No | | | |
| device\_alias
| string | Alphanumeric string to identify a device
| Yes | | | |
| enable | boolean | Enabling/disabling of a device
| No | 1 | 0 | 1 |
| protocol | string | Protocol to be used
| Yes | | IEC 60870-5-103 master |
| device | string
| Communication port
| Yes
| | PORT1
| PORT2
|
| baudrate | integer | Communication speed, baud/s
| No
| 9600
| 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200
|
| databits | integer | Data bit count for communication
| No
| 8
| 8
|
| stopbits | integer | Stop bit count for communication
| No
| 1
| 1
| 2
|
| parity | string
| Communication parity option
| No
| none
| none, even, odd
|
| flowcontrol | string
| Number of requests, before link is considered lost (device status signals are changed) and reconnect attempt will be issued
| No
| none
| none
|
| link\_address | integer | Destination address when in transmit and source address when broadcasting | Yes | | 0 | 65535 |
| asdu\_address | integer | Application Service Data Unit address | Yes | | 0 | 65535 |
| time\_sync\_interval\_sec | integer | Time frame between Time Synchronization
requests in seconds | No | 60 | | |
| gi\_interval\_sec | integer | Time frame between General Interrogation requests in seconds, if 0 requests are disabled | No | 300 | | |
| scan\_rate\_ms | integer | Polling interval in milliseconds. Time frame between two telegrams from master
| No | 100 | | |
| timeout\_ms | integer | Response timeout in milliseconds
| No
| 1000
| | |
| serial\_delay | integer | Communication device’s serial delay in milliseconds. Time frame in which master station is not TX’ing after last RX byte | No | 50 | | |
| retry\_count | integer | Number of retries of failed requests before announcing that device is in Error state
| No | 3 | | |
| retry\_delay\_ms | integer | Time before the next retry in milliseconds | No | 500 | | |
##### IEC 60870-5-103 master parameters for Signals tab
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range**
|
| Min | Max |
| signal\_name
| string | User-friendly signal name
| Yes | | | |
| device\_alias
| string | Alphanumeric string to identify a device
| Yes | | | |
| signal\_alias
| string | Unique alphanumeric name of the signal to be Yes used
| Yes | | | |
| source\_device\_alias
| string | device\_alias of a source device
| For commands | | | |
| source\_signal\_alias
| string | signal\_alias of a source signal
| For
commands | | | |
| enable | boolean | Enabling/disabling of an individual signal
| No | 1 | 0 | 1 |
| log
| integer | Allow signal to be logged. If **log is 0 signal** will not be logged. If **log is more than 0** signal will be logged
| No | 0 | | |
| gi | boolean | Including/excluding (1 or 0) signal from General Interrogation | No | 0 | 0 | 1 |
| common\_address | integer | Address of a destination device | Yes | | | |
| function | integer | Function number | No | 0 | | |
| info\_address | integer | Information object address | Yes | | | |
| info\_number | integer | Information number | Yes | | | |
| data\_type | integer | ASDU type identificator | No | 0 | | |
| fleeting | boolean | Mark signal as fleeting type (1 or 0). Fleeting signals have go to DPI::OFF after defined time | No | | 0 | 1 |
| normalise\_time\_ms | integer | Time in milliseconds between station receiving DPI::ON and automatically switching to DPI::OFF | If fleeting is used | 100 | | |
IEC 60870-5-103 has an additional signal which can be configured to show communication status. It is used to indicate if the slave device has disconnected from master (WCC Lite). To configure such signal, two columns should be filled with particular values. To a newly created additional signal one should make **job\_todo** equal to device\_status and **tag\_job\_todo** equal to communication\_status.
### Debugging a IEC 60870-5-103 Master aplication
If configuration for IEC 60870-5-103 devices is set up, the handler for the protocol will start automatically. If a configuration is missing or contains errors, the protocol will not start. It is done intentionally to decrease unnecessary memory usage.
If IEC 60870-5-103 does not work properly (e.g. no communication between devices, data is corrupted, etc.), a user can launch a debug session from command-line interface and find out why link is not functioning properly or use WCC Utility to do that.
To launch a debugging session, a user should stop the iec103-master process and run the iec103-master command with respective flags.
- Step 1: Service must be stopped by entering the following command into the wcclite:
**/etc/init.d/iec103-master stop**
- Step 2: After service is stopped it must be started with the preferred configuration file (JSON
files found in /etc/ folder) and a debug level 7: **iec103-master -c /etc/iec/iec103-master.json -d7**
- Step 3: Once the problem is diagnosed normal operations can be resumed with the following command: **/etc/init.d/iec103-master start**
##### IEC 60870-5-103 command line debugging options
```
-h [ –help ] Display help information
-V [ –version ] Show version
-d Set debugging level
-c [ –config ] Config path
-r [ –raw ] Show raw telegram data
-f [ –frame ] Show frame data
-R [ –readyfile ] Ready notification file
```
To set up TLS connection for both IEC104 Master and Slave, refer to sections Excel configuration and Certificates. All keys and certificates should be provided in the PEM format.
If no configuration is set up, IEC104 Master and Slave services are not started.
#### Configuring IEC 104 Master datapoints
To use IEC 60870-5-104 Master in WCC Lite, it has to be configured via an Excel configuration. This configuration contains two Excel sheets where parameters have to be filled in Devices and Signals.
##### IEC 60870-5-104 Master parameters for *Devices* tab
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range
|
| Min | Max |
| name
| string | User-friendly name for a device
| Yes | | | |
| description
| string | Description of a device
| No | | | |
| device\_alias
| string | Alphanumeric string to identify a device
| Yes | | | |
| enable | boolean | Enabling/disabling of a device
| No | 1 | 0 | 1 |
| protocol | string | Protocol to be used
| Yes | | IEC 60870-5-104 master |
| asdu\_address | integer | Application Service Data Unit address | Yes | | 0 | 65535 |
| asdu\_size | integer | Common address size in bytes | No | 2 | 1 | 3 |
| time\_sync\_interval\_sec | integer | Time frame between Time Synchronization
requests in seconds | No | 60 | | |
| gi\_interval\_sec | integer | Time frame between General Interrogation requests in seconds, if 0 requests are disabled | No | 300 | | |
| port | integer | TCP port | Yes | | 0 | 65535 |
| ioa\_size | integer | Information object address (IOA) size in bytes | No | 3 | 1 | 3 |
| swt | integer | Send window (SWT) | Yes | | | |
| rwt | integer | Receive window (RWT) | Yes | | | |
| cot\_size | integer | Cause of transmission (COT) size in bytes | No | 2 | 1 | 2 |
| host | string | Host IP address (ipv4) | Yes | | | |
| t1
| integer | Acknowledge timeout t1 (sec) | Yes | | | |
| t2 | integer | Connection ACKRSN clock t2 (sec) | Yes | | | |
| t3 | integer | Connection TESTFR clock t3 (sec) | Yes | | | |
| originator | integer | Provides a means for a controlling station toexplicitly identify itself | No | 0 | 0 | 255 |
##### IEC 60870-5-104 Master parameters for *Signals* tab
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range**
|
| Min | Max |
| signal\_name
| string | User-friendly signal name
| Yes | | | |
| device\_alias
| string | Alphanumeric string to identify a device
| Yes | | | |
| signal\_alias
| string | Unique alphanumeric name of the signal to be Yes used
| Yes | | | |
| source\_device\_alias
| string | device\_alias of a source device
| For commands | | | |
| source\_signal\_alias
| string | signal\_alias of a source signal
| For
commands | | | |
| enable | boolean | Enabling/disabling of an individual signal
| No | 1 | 0 | 1 |
| log
| integer | Allow signal to be logged. If **log is 0 signal** will not be logged. If **log is more than 0** signal will be logged
| No | 0 | | |
| gi | boolean | Including/excluding (1 or 0) signal from General Interrogation | No | 0 | 0 | 1 |
| common\_address | integer | Address of a destination device | Yes | | | |
| function | integer | Function number | No | 0 | | |
| info\_address | integer | Information object address | Yes | | | |
| data\_type | integer | ASDU type identificator | No | | | |
| select\_ms | integer | Time limit in milliseconds for command
execution. Command select has to be
performed before execution if this parameter is specified. Direct command execution can be performed only if this field is left empty or set to zero. | No | 0 | | |
### Debugging a IEC 60870-5-104 Master aplication
If configuration for IEC 60870-5-104 devices is set up, the handler for the protocol will start automatically. If a configuration is missing or contains errors, the protocol will not start. It is done intentionally to decrease unnecessary memory usage.
If IEC 60870-5-104 does not work properly (e.g. no communication between devices, data is corrupted, etc.), a user can launch a debug session from command-line interface and find out why link is not functioning properly or use WCC Utility to do that.
To launch a debugging session, a user should stop the *iec104-master* process and run the *iec104-master* command with respective flags.
- Step 1: Service must be stopped by entering the following command into the wcclite:
**/etc/init.d/iec104-master stop**
- Step 2: After service is stopped it must be started with the preferred configuration file (JSON
files found in /etc/ folder) and a debug level 7: **iec104-master -c /etc/iec104-master/iec104-master.json -d7**
- Step 3: Once the problem is diagnosed normal operations can be resumed with the following command: **/etc/init.d/iec104-master start**
##### IEC 60870-5-104 command line debugging options
```
-h [ –help ] Display help information
-V [ –version ] Show version
-d Set debugging level
-c [ –config ] Config path
-r [ –raw ] Show raw telegram data
-f [ –frame ] Show frame data
-e [ –redis ] Show redis message
-R [ –readyfile ] Ready notification file
```
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range
|
| Min | Max |
| name
| string | User-friendly name for a device
| Yes | | | |
| description
| string | Description of a device
| No | | | |
| device\_alias
| string | Alphanumeric string to identify a device
| Yes | | | |
| enable | boolean | Enabling/disabling of a device
| No | 1 | 0 | 1 |
| protocol | string | Protocol to be used
| Yes | | IEC 60870-5-104 slave |
| asdu\_size | integer | Common address size in bytes | No | 2 | 1 | 3 |
| time\_sync | boolean | Enable/disable (1 or 0) time synchronization | Yes | | | |
| port | integer | TCP port | No | 2404 | 0 | 65535 |
| ioa\_size | integer | Information object address (IOA) size in bytes | No | 3 | 1 | 3 |
| swt | integer | Send window (SWT) | No | 12 | | |
| rwt | integer | Receive window (RWT) | No | 8 | | |
| cot\_size | integer | Cause of transmission (COT) size in bytes | No | 2 | 1 | 2 |
| host | string | Space separated remote host IP addresses (ipv4) | Yes | | | |
| bind\_address | string | Bind to local IP address (ipv4) | No | 0.0.0.0 | | |
| t1
| integer | Acknowledge timeout t1 (sec) | Yes | | | |
| t2 | integer | Connection ACKRSN clock t2 (sec) | Yes | | | |
| t3 | integer | Connection TESTFR clock t3 (sec) | Yes | | | |
| sp\_time | boolean | Add (1 or 0) CP56Time2a information to single point signals | No | 0 | 0 | 1 |
| dp\_time | boolean | Add (1 or 0) CP56Time2a information to double point signals | No | 0 | 0 | 1 |
| me\_time | boolean | Add (1 or 0) CP56Time2a information to measurements | No | 0 | 0 | 1 |
| message\_size | boolean | Maximum length of a message | Yes | | 0 | 255 |
| cache\_size | integer | | Yes | | 0 | 1000 |
| tls | boolean | Enable/disable use of TLS | No | 0 | 0 | 1 |
| tls\_local\_certificate | string | Local certificate for TLS connection | Yes (for TLS) | | | |
| tls\_peer\_certificate | string | Certificate authority file for TLS connection | No | | | |
| tls\_private\_key | string | File consisting of private key for TLS
connection | No | | | |
##### IEC 60870-5-104 Slave parameters for *Signals* tab
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range**
|
| Min | Max |
| signal\_name
| string | User-friendly signal name
| Yes | | | |
| device\_alias
| string | Alphanumeric string to identify a device
| Yes | | | |
| signal\_alias
| string | Unique alphanumeric name of the signal to be Yes used
| Yes | | | |
| source\_device\_alias
| string | device\_alias of a source device
| For commands | | | |
| source\_signal\_alias
| string | signal\_alias of a source signal
| For
commands | | | |
| enable | boolean | Enabling/disabling of an individual signal
| No | 1 | 0 | 1 |
| log
| integer | Allow signal to be logged. If **log is 0 signal** will not be logged. If **log is more than 0** signal will be logged
| No | 0 | 0 | 1 |
| gi | boolean | Including/excluding (1 or 0) signal from General Interrogation | No | 0 | 0 | 1 |
| common\_address | integer | Address of a destination device | Yes | | | |
| info\_address | integer | Information object address | Yes | | | |
| data\_type | integer | ASDU type id. Types are identified
automatically if this field is not set. | No | 0 | |
| select\_ms | integer | Time limit in milliseconds for command
execution. Command select has to be
performed before execution if this parameter is specified. Direct command execution can be performed only if this field is left empty or set to zero. | No | 0 | | |
### Debugging a IEC 60870-5-104 Slave aplication
If configuration for IEC 60870-5-104 devices is set up, the handler for the protocol will start automatically. If a configuration is missing or contains errors, the protocol will not start. It is done intentionally to decrease unnecessary memory usage.
If IEC 60870-5-104 does not work properly (e.g. no communication between devices, data is corrupted, etc.), a user can launch a debug session from command-line interface and find out why the link is not functioning properly or use WCC Utility to do that.
To launch a debugging session, a user should stop the *iec104-slave* process and run the *iec104-slave* command with respective flags.
- Step 1: Service must be stopped by entering the following command into the wcclite:
**/etc/init.d/iec104-slave stop**
- Step 2: After service is stopped it must be started with the preferred configuration file (JSON
files found in /etc/ folder) and a debug level 7: **iec104-slave-c /etc/iec104-slave/iec104-slave.json -d7**
- Step 3: Once the problem is diagnosed normal operations can be resumed with the following command: **/etc/init.d/iec107-slave start**
##### IEC 60870-5-10 command line debugging options
```
-h [ –help ] Display help information
-V [ –version ] Show version
-d Set debugging level
-c [ –config ] Config path
-r [ –raw ] Show raw telegram data
-f [ –frame ] Show frame data
-e [ –redis ] Show redis message
-R [ –readyfile ] Ready notification file
```
If **ip** or **port** parameters are configured, any serial port settings are ignored and connections are initiated via TCP.
IEC 62056-21 device configuration parameters:
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range
|
| Min | Max |
| name
| string | User-friendly name for a device
| Yes | | | |
| description
| string | Description of a device
| No | | | |
| device\_alias
| string | Alphanumeric string to identify a device
| Yes | | | |
| enable | boolean | Enabling/disabling of a device
| No | 1 | 0 | 1 |
| protocol | string | Protocol to be used
| Yes | | IEC 62056-21
|
| poll\_delay\_ms | integer | Minimum time delay in miliseconds to wait before sending any data on port. | No | 200 | | |
| scan\_rate\_ms | integer | | | 10000 | | |
| device | string | Communication port | No (for serial) | | PORT1 | PORT2 |
| baudrate | integer
| Communication speed, bauds/s | No (for serial) | 6900 | 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 |
| databits | integer | Data bit count for communication | No (for serial) | 8 | 6 | 9 |
| stopbits | integer | Stop bit count for communication | No (for serial) | 1 | 1 | 2 |
| parity | string | Communication parity option | No (for serial) | NONE | NONE, EVEN, ODD |
| flowcontrol | string | Communication device flow control option | No | | NONE |
| serialnumber | unsigned long | Meter serial number | Yes | | 1 | |
| serial\_close\_delay | integer | Delay before closing serial port | No | 400 | | |
| timeout\_ms | integer | Timeout of waiting for incoming request | No | 2500 | | |
| type | string | Defines a connection mode | No | C | A,B,C |
| t2 | integer | Time to wait before acknowledging the suggested baudrate in mode C | No | 300 | 200 | 1500 |
| ip | string | IP address for TCP connection | Yes (for TCP) | | | |
| port | integer | TCP port | Yes (for TCP) | | 0 | 65535 |
#### Signals section
**tag\_job\_todo** defines the job sub-job. This field should contain the exact representation of the OBIS code as it is configured in the meter. E.g. if the parameter of interest is represented as
”1.8.0\*24(0147238.4\*kWh)”, the value of the configuration field should be ”1.8.0\*24” (excluding quotation marks).
IEC 62056-21 tags configuration parameters:
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range
|
| Min | Max |
| signal\_name | string | User-friendly signal name | Yes | | |
| device\_alias | string | Device alias from a Devices tab | Yes | | | |
| signal\_alias | string
| Unique alphanumeric name of the signal to be use | Yes | | | |
| enable | boolean | | No | 1 | 0 | 1 |
| log | integer | Allow signal to be logged. If **log is 0 signal** will not be logged. If **log is more than 0** signal will be logged | No | 0 | 0 | |
| number\_type | string | Number format type | Yes | | | |
| tag\_job\_todo
| string | Tag job in OBIS format
| Yes | | | |
For **tag\_job\_todo** configuration it is best to first manually read the meter via PC or HHU (hand-held unit) to determine the exact OBIS representation format of the parameter as they can differ between meter manufacturers and utility companies.
# 31 IEC 61850
### Introduction
IEC 61850 is an international standard defining communication protocols for intelligent electronic devices at electrical substations. It is a part of the International Electrotechnical Commission’s (IEC) Technical Committee 57 reference architecture for electric power systems. The abstract data models defined in IEC 61850 can be mapped to a number of protocols. Possible mappings in the standard can be MMS (Manufacturing Message Specification), GOOSE (Generic Object Oriented Substation Event), SMV (Sampled Measured Values). These protocols can run over TCP/IP networks or substation LANs using high speed switched Ethernet to obtain the necessary response times below four milliseconds for protective relaying.
As of version v1.5.0, WCC Lite supports MMS type messaging. Logging and groups setting services are not supported.
### IEC 61850 Server
WCC Lite can act as a IEC 61850 server to serve data to remote SCADA systems. For example, WCC Lite can be used to acquire data from various protocols (Modbus, IEC 60870-5-103, etc.), this data can be redirected and propagated further to a single or multiple IEC 61850 clients. IEC 61850 Server supports TCP and TLS connection types. TCP connection can be secured with password authentication.
#### Commands
WCC Lite **IEC 61850 Server** implementation defines four command types which are described by their control model:
- **Case 1**: Direct control with normal security (direct-operate);
- **Case 2**: SBO control with normal security (operate-once or operate-many);
- **Case 3**: Direct control with enhanced security (direct-operate);
- **Case 4**: SBO control with enhanced security (operate-once or operate-many).
Normal security commands are considered for execution if the command signal is found in Excel configuration. There aren’t any additional checks in command execution in any master protocol.
Enhanced security commands need feedback from master protocol to either to succeed or fail. If feedback is not received within **command\_ack\_timeout\_ms** timeframe, the command is considered as failed.
Command value attributes (e.g. stVal) must be updated separately (if they need to be updated).
When using SBO commands, select is not routed to master protocol and select logic is performed only in IEC 61850 Server protocol.
#### Configuring datapoints
To use IEC 61850 Server in WCC Lite, it has to be configured via an Excel configuration and data model must be uploaded. This configuration contains two Excel sheets where parameters have to befilled in - Devices and Signals.
##### IEC 61850 Server parameters for Devices tab
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range
|
| Min | Max |
| name
| string | User-friendly name for a device | Yes | | | |
| description | string | Description of a device | No | | | |
| device\_alias | string | Alphanumeric string to identify a device | Yes | | | |
| enable | boolean | Enabling/disabling of a device | No | 1 | 0 | 1 |
| protocol | string | Protocol to be used | Yes | | IEC 61850 Server |
| tls | string | Selecting if TLS should be used | No | 0
| 0 | 1 |
| bind\_address | string (IP address format) | IP address of and interface to use with server | No | 0.0.0.0 | |
| host | string (IP address format) | IP address list of allowed IPs (separated with spaces)
| Yes | | | |
| port | integer | TCP communication port
| Yes | | | |
| tls\_local\_certificate | string | Local certificate for TLS connection
| Yes (for TLS) | | |
| tls\_peer\_certificate | string | Certificate authority file for TLS connection | Yes (for TLS) | | |
| tls\_private\_key | string | File consisting of private key for TLS connection | Yes (for TLS) | | | |
| event\_history\_size | integer | Event log size | No | | | |
| ied\_name | string | Name of an Intelligent Electronic Device | Yes | | | |
| authorization | string | Authorization type | No | | password |
| password | string | Authorization password for server device | Yes (if authorization is yes) | | | |
| model\_filename | string | Filename of data model uploaded to WCC (with or without file extension) | Yes | | | |
| edition | string | Which IEC61850 edition to use.
| No | 2 | 1,2, 2.1 |
| command\_ack\_timeout\_ms
| integer | Timeframe (ms) in which enhanced-security commands must be acknowledged
(Default: 3000)
| No | 3000 | | |
| report\_buffered\_size | integer | Report control blocks buffer size in bytes
(Default: 65536)
| No | 65536 | | |
| report\_unbuffered\_size | integer | Unbuffered report control blocks buffer size in bytes (Default: 65513)
| No | 65513 | | |
##### IEC 61850 Server parameters for Signals tab
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range**
|
| Min | Max |
| signal\_name | string | User-friendly signal name | Yes | | | |
| device\_alias | string | Device alias from a Devices tab | Yes | | | |
| signal\_alias | string | Unique alphanumeric name of the signal to be used | Yes | | | |
| enable | boolean | Enabling/disabling of an individual signal | No | 1 | 0 | 1 |
| log | boolean | Allow signal to be logged. If **log is 0 signal** will not be logged. If **log is more than 0** signal will be logged | No | 0 | | |
| number\_type | string | Number format type (BOOLEAN, FLOAT, INT16, etc.) | Yes | | | |
| ld\_instance | string | Instance of a logical device | Yes | | | |
| ln\_class | string | Logical node class type | Yes | | | |
| ln\_instance | integer | Instance of a logical node | No | | | |
| ln\_prefix | string | Prefix of logical node string | No | | | |
| cdc | string | Common Data Class (CDC) name | Yes | | SPS, DPS, INS, ENS, ACT, ACD, MV, CMV, SAV, SPC, DPC, INC, ENC, BSC, ISC, APC, BAC |
| data\_object | string | Name of data object in dataset | Yes | | | |
| da\_value | string | Name of a data attribute value node | Yes | | | |
| da\_time | string | Name of a data attribute time node | No | | | |
| da\_quality | string | Name of a data attribute quality node | No | | | |
| da\_fc | string | Functional constrain for data object | Yes | | ST,MX, CO, SP |
| control\_model | string
| Model of output control
| No
| status-only | status-only,
direct-with-normal-security,
sbo-with-normal-security,
direct-with-enhanced-security, sbo-with-enhanced-security
|
#### Converting and uploading data model
To use IEC61850 Server protocol in WCC Lite, user must upload a data model in specific format (file extension .cfg). These data models can be converted from SCL files (.icd or .cid files). To convert a data model, the user must use WCC Excel Utility. There’s a separate tab for this operation as shown in picture below.
[](https://wiki.elseta.com/uploads/images/gallery/2020-09/image-1601465307717.png)
Converted file can be uploaded in WCC Lite web interface, Protocol Hub section. Current model can be also downloaded in the same page as shown in picture below.
[](https://wiki.elseta.com/uploads/images/gallery/2020-09/image-1601465353342.png)
#### Debugging a IEC 61850 server application
If configuration for IEC 61850 Server is set up, handler for protocol will start automatically. If configuration is missing or contains errors, protocol will not start. It is done intentionally to decrease unnecessary memory usage.
If IEC 61850 Server does not work properly (e.g. no communication between devices, data is corrupted, etc.), a user can launch a debug session from command line interface and find out why link is not functioning properly.
To launch a debugging session, a user should stop `iec61850-server` process and run` iec61850-server` command with respective flags as you can see below:
`iec61850-server `
```iec61850-server
-h [--help] Show help message
-c [--config] arg Configuration file location
-V [--version] Show version
-d [--debug] arg Set Debug level
-r [--redis] Show Redis messages
-C [--commands] Show command messages
-R [--readyfile] arg Ready notification file
```
### IEC 61850 Client
WCC Lite can be used as a master station to collect data from IEC 61850 compatible server devices such as protection relays. As relays require fast, secure and responsive interfaces, WCC Lite can be considered as a valid option. For additional security a user can use encrypted transmission (TLS) or set up a password.
As TCP (TLS) connection can encounter issues and break, automatic reconnection is implemented. After every failed reconnection attempt the fallback delay is doubled starting from 1 second up until 32 seconds. After that connection reestablishment will be attempted every 32 seconds until a successful connection.
#### Acquiring data via report control blocks
As per IEC 61850 standard, the report control block controls the procedures that are required for reporting values of data objects from one or more logical nodes to one client. Automatic reporting enables data servers (slave devices) to only send data on its (or its quality) change, thus saving network bandwith. Instances of report control blocks are configured in the server at configuration time.
Report control blocks send information that is defined in their respective datasets. Dataset is a set of data elements grouped to represent some data group. For example, it is a common practice to group measurements and events into different groups.
A server restricts access to an instance of a report control block to one client at a time. That client exclusively shall own that instance and shall receive reports from that instance of report control blocks. There are two classes of report control blocks defined, each with a slightly different behaviour:
- buffered-report-control-block (BRCB) - internal events (caused by trigger options data-change, quality-change, and data-update) issue immediate sending of reports or buffer the events (to some practical limit) for transmission, such that values of data object are not lost due to transport flow control constraints or loss of connection. BRCB provides the sequence-of-events (SOE) functionality;
- unbuffered-report-control-block (URCB) - internal events (caused by trigger options data-change, quality-change, and data-update) issue immediate sending of reports on a best efforts basis. If no association exists, or if the transport data flow is not fast enough to support it, events may be lost.
Buffered report control blocks are therefore useful to keep event data, for example, keeping the last known state of a relay switch where a loss of information might lead to a confusion and even financial losses. Unbuffered report control blocks are particularly useful for data which is useful only momentarily, e.g. measurements of voltages, current or power. This information can change frequently and old measurements might not reflect the real state of a substation.
To allow multiple clients to receive the same values of data object, multiple instances of the report control classes shall be made available.
Buffered report control blocks are usually configured to be used by a specific client implementing a well-defined functionality, for example, a SCADA master. The client may know the ObjectReference of the BRCB by configuration or by the use of a naming convention.
Parsing of report control blocks is based on types of Common Data Class (CDC). Some of these types can have more then one data point of interest. Table below shows what data attributes are supported from various Common Data Classes. To select which data attribute should be used a `da_value` column should be filled with a data attribute name. Common Data Classes consist of data attributes with different Functional Constraints therefore to get the status points of interest correctly the user must fill in a correct value in `da_fc` column.
IEC 61850 Client supported data attributes:
| Common Data Class | Function Constraint | Data attributes |
| SPS
DPS
INS
ENS
| ST | stVal |
| ACT | ST | general
phsA
phsB
phsC
neut
|
| ACD | ST | general
dirGeneral
phsA
dirPhsA
phsB
dirPhsB
phsC
dirPhsC
neut
dirNeut
|
| MV | MX | instMag
mag
|
| CMV | MX | instCVal
cVal
|
| SAV | MX | instMag |
| SPC
DPC
INC
ENC
| ST | stVal |
| BSC
ISC
| ST | valWTr |
| APC
BAC
| MX | mxVal |
Some of data attributes are structures themselves, for example, `mag` attribute is a struct that can hold integer or float values. To select a fitting attribute the user should extend `da_value` parameter with additional attributes, for example, if float magnitude value is to be selected from MV Common Data Class, `da_value` column should be filled with `mag.f` value; if the user intends `cVal` magnitude value in float format from CMV Common Data Class, `da_value` should be filled with `cVal.mag.f` value. See IEC 61850-7-3 for more information about Common Data Classes.
To ensure the integrity of configuration, WCC Lite has additional checks implemented at configuration time. If report control block (or its dataset) with a predefined ObjectReference doesn’t exist, it is considered that IEC 61850 Client has not been configured properly or configuration has been changed in either of IEC 61850 devices and cannot be matched, therefore should be considered invalid.
#### Number Types
IEC 61580 has a distinct number\_type field when compared to other protocols.
| **number\_type** |
| BOOLEAN |
| INT8 |
| INT16 |
| INT32 |
| INT64 |
| INT128 |
| INT8U |
| INT24U |
| INT32U |
| FLOAT32 |
| FLOAT64 |
| ENUMERATED |
| OCTET STRING 6 |
| OCTET STRING 8 |
| OCTET STRING 64 |
| VISIBLE STRING 32 |
| VISIBLE STRING 64 |
| VISIBLE STRING 65 |
| VISIBLE STRING 129 |
| UNICODE STRING 255 |
| TIMESTAMP |
| QUALITY |
| CHECK |
| CODEDENUM |
| GENERIC BITSTRING |
| CONSTRUCTED |
| ENTRY TIME |
| PHYCOMADDR |
| CURRENCY |
| OPTFLDS |
| TRGOPS |
#### Controlling remote equipment via commands
The control model provides a specific way to change the state of internal and external processes by a client. The control model can only be applied to data object instances of a controllable Common Data Class (CDC) and whose ctlModel DataAttribute is not set to status - only. Such data objects can be referred to as control objects. If controls are enabled in a IEC 61850 Server device the user can configure controls by filling control\_model column in Excel configuration with a control model (*direct-with-normal-security, sbo-with-normal-security, direct-with-enhanced-security, sbo-with-enhanced-security*) as well as setting functional constraint in `da_fc` column to CO.
Depending on the application, different behaviours of a control object shall be used. Therefore, different state machines are defined. Four cases are defined:
- **Case 1**: Direct control with normal security (direct-operate);
- **Case 2**: SBO control with normal security (operate-once or operate-many);
- **Case 3**: Direct control with enhanced security (direct-operate);
- **Case 4**: SBO control with enhanced security (operate-once or operate-many).
IEC 61850 standard enables the user to plan command transmission in advance - set the timer when the command should be issued. However, as this possibility is rarely used in practice, it is not implemented as of version v1.5.0. All issued commands are executed immediately.
For more information on control class model, please consult IEC 61850-7-2 standard.
If ctlModel is read-only, messages from internal database will be ignored for this point, otherwise a subscribe callback will be launched to handle commands as soon as they are sent. If CDC of a signal does not have means of control, ctlModel parameter is ignored.
Originator identification can be attached to a station so that replies to command requests could be forwarded to only one device. To use this functionality a user should select an origin identificator by filling value in Excel configuration, originator column. Originator category is always enforced to tell that remote control command is issued.
#### Configuring datapoints
To use IEC 61850 Client in WCC Lite, it has to be configured via an Excel configuration. This configuration contains two Excel sheets where parameters have to be filled in - Devices and Signals tables.
##### Table IEC 61850 Client parameters for *Devices* tab
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range
|
| Min | Max |
| name
| string | User-friendly name for a device | Yes | | | |
| description | string | Description of a device | No | | | |
| device\_alias | string | Alphanumeric string to identify a device | Yes | | | |
| enable | boolean | Enabling/disabling of a device | No | 1 | 0 | 1 |
| protocol | string | Protocol to be used | Yes | | IEC 61850 Client |
| tls | string | Selecting if TLS should be used | No | 0
| 0 | 1 |
| host | string (IP address format) | IP address of server device
| Yes | 0.0.0.0 | | |
| port | integer | TCP communication port
| Yes | 102 | | |
| tls\_local\_certificate | string | Local certificate for TLS connection
| Yes (for TLS) | | | |
| tls\_peer\_certificate | string | Certificate authority file for TLS connection | Yes (for TLS) | | | |
| tls\_private\_key | string | File consisting of private key for TLS connection | Yes (for TLS) | | | |
| event\_history\_size | integer | Event log size | No | | | |
| ied\_name | string | Name of an Intelligent Electronic Device | Yes | | | |
| authorization | string | Authorization type | No | | password | |
| password | string | Authorization password for server device | No | | | |
| originator | string | Origin identificator for device
| No | | | |
##### Table IEC 61850 Client parameters for *Signals* tab
| **Parameter**
| **Type**
| **Description**
| **Required**
| **Default Value**
(when not specified)
| **Range**
|
| Min | Max |
| signal\_name | string | User-friendly signal name | Yes | | | |
| device\_alias | string | Device alias from a Devices tab | Yes | | | |
| signal\_alias | string | Unique alphanumeric name of the signal to be used | Yes | | | |
| enable | boolean | Enabling/disabling of an individual signal | No | 1 | 0 | 1 |
| log | boolean | Allow signal to be logged. If **log is 0 signal** will not be logged. If **log is more than 0** signal will be logged | No | 0 | | |
| number\_type | string | Number format type | Yes | | | |
| ld\_instance | string | Instance of a logical device | Yes | | | |
| ln\_class | string | Logical node class type | Yes | | | |
| ln\_instance | integer | Instance of a logical node | No | | | |
| ln\_prefix | string | Prefix of logical node string | No | | | |
| cdc | string | Common Data Class (CDC) name | Yes | | SPS, DPS, INS, ENS, ACT, ACD, MV, CMV, SAV, SPC, DPC, INC, ENC, BSC, ISC, APC, BAC |
| data\_object | string | Name of data object in dataset | Yes | | | |
| da\_value | string | Name of a data attribute value node | Yes | | | |
| da\_fc | string | Functional constrain for data object | Yes | | ST,MX, CO, SP |
| control\_model | string
| Model of output control
| No
| status-only | status-only,
direct-with-normal-security,
sbo-with-normal-security,
direct-with-enhanced-security, sbo-with-enhanced-security
|
| dataset
| string
| Full object reference of a dataset
| Yes
| | | |
| report\_control\_block
| string
| Full object reference of a report control block
| Yes
| | |
| intgPd
| integer
| Integrity period in milliseconds
| No
| 0 | | |
It should be noted that ACT and ACD messages can only be parsed from report if either only ‘general’ attribute or all attributes attached to all three phases and neutral can be found in report
IEC 61850 Client has an additional signal which can be configured to show communication status. It is used to indicate if the server device has disconnected from client (WCC Lite). To configure such signal, two columns should be filled with particular values. To a newly created additional signal one should make `job_todo` equal to device\_status and `tag_job_todo` equal to communication\_status. Communication error status is set after a disconnection of a server device.
#### Debugging a IEC 61850 Client application
If configuration for IEC 61850 Client is set up, handler for protocol will start automatically. If configuration is missing or contains errors, protocol will not start. It is done intentionally to decrease unnecessary memory usage.
IEC 61850 Client command line debugging options
`iec61850-client`
```
-h [ –help ] Show help message
-c [–config] arg Configuration file location
-V [–version] Show version
-d [–debug] arg Set debugging level
-r [–redis] Show Redis messages
-C [–commands] Show command messages
-D [–datasets] Show dataset messages
–report Show report messages
-R [–readyfile] arg Ready notification file
```
If IEC 61850 Client does not work properly (e.g. no communication between devices, data is corrupted, etc.), a user can launch a debug session from command line interface and find out why link is not functioning properly.
To launch a debugging session, a user should stop `iec61850-client` process and run `iec61850-client` command with respective flags as was shown above.
# 32 WCC Lite internal signals
### Overview
The WCC Lite contains several internal data points for readout and control which can be accessed via the Pooler service.
### Configuration
#### Devices section
In the devices section, only the protocol, scan\_rate\_ms and poll\_delay\_ms are to be configured for this type of device.
##### WCC Lite internal signals
| **Parameter** | **Type** | **Description** | **Required** | **Default Value**
(when not specified)
| **Range**
|
| name | string
| User-friendly device name | Yes | | |
| device\_alias | string | Alphanumeric string to identify a device | Yes | | |
| protocol | | Protocol identifier Internal data | Yes | | **Internal data** |
| scan\_rate\_ms | integer | Update rate | No | 60000 | |
| poll\_delay\_ms | integer | Poll delay | No | 200 | |
It is advised to set scan\_rate\_ms to a value greater than 5000 ms as frequent scans may result in significant overload of the pooler process.
#### Signals section
`tag_job` defines the tag job. This can be set to `gpio`, `board`, `netstat`, `led` and `process`. `tag_job_todo` defines the job sub job. This field should address the particular point of interest.
| **job\_todo** | **Description** | **tag\_job\_todo** | **Description** |
| gpio
| Get GPIO | GPIO number | Use number 11 for onboard
digital input; SIM select 12;
SIM detect 20 |
| Set GPIO | \[integer\]|\[1/0\] | Set gpio number to high or low |
| board
| Board info
| active-sim-iccid | Active SIM ICCID |
| active-sim | Active SIM card |
| cpu-usage | CPU usage |
| duid | DUID |
| fw-version | Firmware version |
| gsm-available-rat | GSM available radio access
technologies |
| gsm-current-rat | GSM current radio access
technology |
| gsm-current-rat-num | GSM current radio access
technology identifier |
| gsm-imsi | GSM IMSI number |
| gsm-internet-status | GSM Internet status |
| internet-status | Same as gsm-internet-status |
| gsm-network-reg-status | GSM network register status |
| gsm-operator | GSM operator |
| gsm-operator-num | GSM operator number |
| gsm-roaming-status | GSM roaming status |
| gsm-selected-rat | GSM selected rat |
| gsm-service-provider | GSM service provider |
| gsm-signal-quality | GSM signal quality |
| gsm-signal-quality-num | GSM signal quality (dBm) |
| gsm-sig-quality | Same as gsm-signal-quality-num |
| hostname | Hostname |
| hw-info | Hardware information |
| modem-imei | Modem IMEI number |
| modem-manufacturer | Modem manufacturer name |
| modem-model | Modem model |
| modem-type | Modem type |
| ram-usage | RAM usage |
| sim-status | SIM card status |
| uuid | UUID |
| netstat|\[interface\] | Network statistics | TX
| Bytes transferred |
| RX | Bytes received |
| smsstat
| SMS statistics
| received
| SMS received |
| sent
| SMS sent |
| call
| SMS call |
| failed
| SMS failed |
| led
| LED status/control
| ath9k-phy0 | WLAN LED |
| wcclite:blue:heartbeat | Status LED |
| wcclite:blue:wlan | WLAN LED |
| wcclite:green:eth0 | ETH0 LED |
| wcclite:green:eth1 | ETH1 LED |
| wcclite:green:signal1 | Signal 1 LED |
| wcclite:green:signal2 | Signal 2 LED |
| wcclite:green:signal3 | Signal 3 LED |
| wcclite:gsm-rst | GSM LED |
| wcclite:red:fault | Fault LED |
| wcclite:rs232-en | RS LED |
| wcclite:relay | Relay LED & Output |
| process | Check if process is running | \[process name\] | 1 or 0 is returned |
Assigning source signals to tags other than wcclite:relay may cause undesirable effects. Signals other than wcclite:relay should be used for monitoring only.
# 33.1 Devices configuration
Protocol HUB uses configuration in excel file format. Each sheet represents a specific part of configuration:
- **Devices** contains device list and protocol related configuration.
- **Signals** contains a list of signals and their options.
First line on each sheet is a header row that contains parameter name for each column. Header order determines parameter names for each following row. Every line after the header is a new entry. An empty row is interpreted as end of sheet. Any rows after empty row are discarded.
### Devices sheet
Devices sheet contains all devices to be configured on gateway. Each row represents one device and its settings. Following options are required for each device:
- **name** - Name of the device. Used for representation only.
- **description** - A short description for the device. Used for representation only.
- **device\_alias** - A unique short name for the device. It is used for linking signals to a device.
Alias can only contain alphanumeric characters and dashes ( - and \_ ). Alias must be unique for each device.
- **protocol** - Protocol type to use on device. Exact values of protocols are writen in every protocol documentation. Please look into range of supported protocols:
**IEC 61850 MMS:**
– IEC 61850 Client (since FW 1.5.0)
– IEC 61850 Server (since FW 1.5.0)
**IEC 60870-5:**
– IEC 60870-5-101 master
– IEC 60870-5-101 slave
– IEC 60870-5-103 master
– IEC 60870-5-104 master
\- IEC 60870-5-104 slave
**DNP 3.0 Serial/LAN/WAN:**
\- DNP3 Master
– DNP3 Slave
**Modbus Serial/TCP:**
\- Modbus RTU/ASCII
– Modbus TCP
**Metering protocols:**
\- DLMS/COSEM (since FW 1.3.0)
– IEC 62056-21 (since FW 1.2.13)
– MBus Serial
– MBus TCP
– Elgama (Meters based on IEC 62056-21 / 31 protocols)
**Industrial IOT protocols:**
\- MQTT
\- RESTful API
**Specific protocols:**
– Aurora (ABB PV inverters protocol)
– PowerOne (ABB PV inverters protocol)
– SMA Net (SMA PV inverters protocol)
– Kaco (Kaco PV inverters protocol)
– Ginlong (Ginlong PV inverters protocol)
– Solplus (Solutronic AG PV inverters protocol)
– ComLynx (Danfoss PV inverters protocol)
– Delta (Delta PV inverters protocol)
– Windlog (Wind sensors from RainWise Inc.)
– Vestas ( Wind turbines protocol)
– Internal data
– VBus.
Although device name rules aren’t strictly enforced, it is highly advised to give a unique name for every new device. Identical device names might introduce confusion while searching for signal in Imported Signals tab.
#### Optional settings
- **enable** - Flag to enable or disable device on system. Can contain values 0 or 1.
- **event\_history\_size** - Maximum number of signal events to save on device for later review. Older records will be erased. This feature is only available on cloud firmware.
#### Serial port settings
Required for any protocol that uses serial line communication.
- **device** - Serial port for communication **(PORT1/PORT2)**
- **baudrate** - Serial port speed. Valid values:
– 300
– 600
– 1200
– 2400
– 4800
– 9600
– 19200
– 38400
– 57600
– 115200
- **databits** - Number of data bits (6-9)
- **stopbits** - Number of stop bits (1-2)
- **parity** - Parity mode (none/even/odd)
- **flowcontrol** - Flow control method (none/hardware/software)
#### TCP/IP settings
Settings for any protocol that uses communication over TCP/IP. Note that all TLS certificates and keys are stored in single folder therefore only name and not the path should be filled in respective fields.
TLS fields are only supported for IEC 61850 Client and Server, IEC-60870-5-104 Slave and DNP3 Master and Slave.
- **ip** - IP address for master protocol to connect to;
- **bind\_address** - one of local IP addresses to bind the server to. Connections through other network devices will be ignored;
- **host** - space separated host IP addresses of master devices;
- **port** - TCP port to listen for incoming connections;
- **tls\_local\_certificate** - name of local TLS certificate;
- **tls\_peer\_certificate** - name of certificate authority (CA) TLS certificate;
- **tls\_private\_key** - name of private key for making TLS connections.# 33.2 Signals Configuration
The signals sheet contains all signals linked to devices. Each signal is defined in a single row. The Signal list can be split into multiple sheets. Each sheet name may start as Signals.
### Required attributes
These attributes are mandatory for every configured signal. Every Excel configuration should have specified them in the first row of the Signals sheet:
- **signal\_name** - Name of the signal. Used for representation only.
- **device\_alias** - Alias of a device defined in Devices sheet. A signal is linked to a matching device.
- **signal\_alias** - A unique short name for the signal. It is used for linking signals to other signals. The alias can only contain alphanumeric characters and dashes ( - and \_ ). Device and signal alias combination must be unique.
- **source\_device\_alias** - Alias of a source device defined in Devices sheet. If a user intends to use several signals and combine them via mathematical or logical function, every alias should be separated by a newline symbol (in the same cell). An operation used must also be defined in an operation column.
- **source\_signal\_alias** - Alias of a source signal defined in Signals sheet. If a user intends to use several signals and combine them via mathematical or logical function, every alias should be separated by a newline symbol (in the same cell). An operation used must also be defined in an operation column. Each `source_signal_alias` should be posted in the same line as its respective `source_device_alias`. Aliases can only contain alphanumeric characters and dashes ( - and \_ ). Device and signal alias combination must be unique.
- **enable** - Flag to enable or disable signal on the system. Can contain values 0 or 1.
- **tag\_type** - Tag type. Simple signals are polled from the device. Virtual signals are computed
internally.
- **off\_message** - Message to display when a single point or double point signals are in OFF state.
- **on\_message** - Message to display when a single point or double point signals are in ON state.
- **units** - Signal value measurements units.
- **multiply** - Multiply value by this number.
- **add** - Add this number to a value.
- **sum\_signals** - Define other signal values to add to the current signal. This field uses following **format**: dev\_alias/tag\_alias. Multiple signals can be defined using commas.
- **min\_value** - Minimum expected value. If the result is lower than this value, the invalid flag is raised.
- **max\_value** - Maximum expected value. If the result is higher than this value, the overflow flag is raised.
- **absolute\_threshold** - Absolute threshold level.
- **integral\_threshold** - Integral threshold level.
- **integral\_threshold\_interval** - Integral threshold addition interval in milliseconds.
- **threshold\_units** - Units used in threshold level fields (percent/real).
- **log\_size** - Maximum number of records for this tag to keep in storage for CloudIndustries logging.
- **suppression\_values** - Space-separated numeric values to be used in suppression.
- **suppression\_time\_ms** - Suppression time in milliseconds.
- **operation** - Mathematical or logical operation to be used for signals defined in source\_signal\_alias column. Following mathematical operations for source signal values can be used: avg (average of all values), min (lowest value), max (highest value), median (median value), and sum (all values accumulated to a single number). Logical operations, intended for unsigned integers only.
- **bit\_select** - selecting an individual bit of an integer number; bit numeration starts from zero.
- **math\_expression** - a mathematical expression for signal value to be evaluated against. Explained in detail in
**Mathematical expressions document**.
Picture. Result of using an absolute threshold:
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601977355078.png)
Picture. Result of using an integral threshold:
### Signal recalculation operation priority
A value generated by some protocol usually has to be recalculated in one way or another. This might mean changing the value of an argument as well as adding flags needed for other protocols to correctly interpret results. As recalculation is a sequential process, some actions are done before others. The sequence of operations done to a value is as follows:
- *Edition of attributes*. Attributes for further interpretation are added. This might, for example, include a flag to show that a signal resembles an answer to a command;
- *Mathematical calculations*. **multiply**, **add**, **bit\_select,** and **math\_expression** columns are evaluated here;
- *Usage of last value*. Decision if last value for a signal should be used if a new value of a signal is not a number (NaN) or contains a non-topical (NT) flag;
- *Limiting of values*. If a value exceeds a lower or higher configured limit, value is approximated not be lower (or higher) than the limit. An additional invalid (IV) or overflow (OV) flag is added as frequently used in IEC-60870-5 protocols;
- *Suppresion of values*. As electrical circuits can be noisy, protocols may generate multiple values in a short amount of time. What is more, some values are considered as intermediary and ideally should not be sent to SCADA unless they stay in the same state for some amount of time. **suppression\_values** and **suppression\_time\_ms** are used to configure this functionality;
- *Threshold* checking. If a new signal doesn’t cross a threshold target value, value is supressed and not used in further stages. **absolute\_threshold, integral\_threshold, integral\_threshold\_interval, threshold\_units** columns are used to configure this functionality.
Not all of the elements in this sequence have to configured, missing operation are skipped and values are fed to a further stage of signal recalculation.
### `number_type` field
This field is required for some protocols to determine a method to retrieve a signal value from hexadecimal form. Available values:
• **FLOAT** - 32-bit single precision floating point value according to IEEE 754 standard
• **DOUBLE** - 64-bit double precision floating point value according to IEEE 754 standard
• **DIGITAL** - 1-bit boolean value
• **UNSIGNED8** - 8-bit unsigned integer (0 - 255)
• **SIGNED8** - 8-bit signed integer (-128 - 127)
• **UNSIGNED16** - 16-bit unsigned integer (0 - 65535)
• **SIGNED16** - 16-bit signed integer (-32768 - 32767)
• **UNSIGNED32** - 32-bit unsigned integer (0 - 4294967295)
• **SIGNED32** - 32-bit signed integer (-2147483648 - 2147483647)
• **UNSIGNED64** - 64-bit unsigned integer (0 - 18446744073709551615)
• **SIGNED64** - 64-bit signed integer (-9223372036854775808 - 9223372036854775807)
Number conversion uses **big endian** byte order by default. Converted data will be invalid if byte order on connected device side is different. In such case byte swap operations can be used. Adding swap prefixes to number type will set different a byte order while converting values. Following swap operations are available:
- **SW8** - Swap every pair of bytes (8 bits) (e.g., **0xAABBCCDD** is translated to **0xBBAADDCC**);
- **SW16** - Swap every pair of words (16 bits) (e.g., **0xAABBCCDD** is translated to **0xCCDDAABB**);
- **SW32** - Swap every pair of two words (32 bits) (e.g., **0x1122334455667788** is translated to **0x5566778811223344**);
| Address | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Original number | Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 |
| SW8 | Byte 1 | Byte 0 | Byte 3 | Byte 2 | Byte 5 | Byte 4 | Byte 7 | Byte 6 |
| SW16 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | Byte 1 | Byte 6 | Byte 4 | Byte 5 |
| SW32 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
| SW8.SW16 | Byte 3 | Byte 2 | Byte 1 | Byte 0 | Byte 7 | Byte 6 | Byte 5 | Byte 4 |
| SW8.SW32 | Byte 5 | Byte 4 | Byte 7 | Byte 6 | Byte 1 | Byte 0 | Byte 3 | Byte 2 |
| SW8.SW16.SW32 | Byte 7 | Byte 6 | Byte 5 | Byte 4 | Byte 3 | Byte 2 | Byte 1 | Byte 0
|
Where Byte x, means bit x position in byte.
Add a dot separated prefix to number format to use byte swapping. Multiple swap operations can be used simultaneously. For example, use `SW8.SW16.SIGNED32` to correctly parse a 32-bit signed integer in a little endian format. Table 35 shows in detail how bytes, words or double words can be swapped and how swapping functions can be combined to make different swapping patterns. Table shows how byte swap is done for 64-bit (8-byte) numbers. It doesn’t matter if it is an unsigned/signed integer or double, byte swapping is considered a bit-level operation. If a number is shorter than 64 bits, the same logic applies, the only difference is unavailability of some swapping operations (`SW32` for 32-bit and smaller numbers). Using such unavailable operation might lead to an undefined behaviour.
### Linking signals
Signals can be linked together to achieve data transfer between several protocols. If a signal source is defined, all output from that source will be routed to the input of target signal. This way events polled from a modbus device (e.g., [Modbus](https://wiki.elseta.com/books/rtu-usage/page/modbus "Modbus protocol"), [IEC 60870-5](https://wiki.elseta.com/books/rtu-usage/chapter/protocols-configuration "Protocols - configuration"), etc.) can be delivered to external station over a different protocol. A signal source is required if a signal is created on a slave protocol configuration to link events between protocols.
#### Example 1:
To read a coil state from a Modbus device and transfer it to [IEC 60870-5-104](https://wiki.elseta.com/books/rtu-usage/page/iec-60870-5-104 "IEC 60870-5-104") station, following steps may be taken:
1. Create a Modbus master configuration in Devices sheet.
2. Create a IEC 60870-5-104 slave configuration in Devices sheet.
3. Create a signal on master device to read coil status (function 1).
4. Create a signal on slave device with single point type (data\_type = 1).
5. Set **source\_device\_alias** and **source\_signal\_alias** fields on slave device signal to match **device\_alias** and **ignal\_alias** on master device’s coil signal.
1. Follow steps 1-3 from example 1.
2. Create a signal on slave device with single command type (data\_type = 45).
3. Set source\_device\_alias and source\_signal\_alias fields on master configuration coil signal to match device\_alias and signal\_alias on slave device’s command signal. Coil will be written to a value received by a command.
4. Set source\_device\_alias and source\_signal\_alias fields on command signal to match device\_alias and signal\_alias on master device’s coil signal. A command termination signal will be reported to the station on coil write result.
For additional information regarding the configuration of IEC 60870-5-101/103/104 protocols, please refer to ”IEC 60780-5-101/103/104 PID interoperability for WCC Lite devices”, accordingly.
### Introduction
Signal value might require some recalculation or signal update prior to being sent. Understandably, existing columns in Excel configuration like `multiply`, `add`, `bit_select` might not be flexible enough. To overcome these limitations, symbolic mathematical expressions can be configured to do calculations automatically on every update of a signal.
It should be noted that filling mathematical expression disables other mathematical scalar operations for a single value such as `multiply`, `add` or `bit_select`. Other functions (primarily between several signals) are still available such as operation.
### Feature list:
- Optimized for speed
- High parsing performance
- if-then-else operator with lazy evaluation
- Default implementaion with many features
- 25 predefined functions
- 18 predefined operators
- Unit support
- Use postfix operators as unit multipliers (3m -> 0.003)
### Mathematical functions
Table. Supported mathematical functions:
| Name | Argument count | Explanation |
| sin | 1 | sine function (rad)
|
| cos | 1 | cosine function (rad)
|
| tan | 1 | tangent function (rad)
|
| asin | 1 | arcus sine function (rad)
|
| acos | 1 | arcus cosine function (rad)
|
| atan | 1 | arcus tangens function (rad)
|
| sinh
| 1 | hyperbolic sine function
|
| cosh | 1 | hyperbolic cosine
|
| tanh | 1 | hyperbolic tangens function
|
| asinh | 1 | hyperbolic arcus sine function
|
| acosh | 1 | hyperbolic arcus tangens function
|
| atanh | 1 | hyperbolic arcur tangens function
|
| log2 | 1 | logarithm to the base 2
|
| log10 | 1 | logarithm to the base 10
|
| log | 1 | logarithm to base e (2.71828...)
|
| ln | 1 | logarithm to base e (2.71828...)
|
| exp | 1 | e raised to the power of x
|
| sqrt | 1 | square root of a value
|
| sign | 1 | sign function -1 if x<0; 1 if x>0
|
| rint | 1 | round to nearest integer
|
| abs | 1 | absolute value
|
| min | variable | min of all arguments
|
| max | variable | max of all arguments
|
| sum | variable | sum of all arguments
|
| avg | variable | mean value of all arguments
|
It should be noted that trigonometric functions (excluding hiperbolic functions) only support arguments in radians. This means that arguments for this function have to be recalculated if angle is defined in degress.
Value recalculation is only triggered on signal change of the preconfigured signal. That means that using other signals (via TagValue() call) does not trigger value update.
Some mathematical expression cannot be mathematically evaluated in some conditions, for example, square root cannot be found for negative numbers. As complex numbers are not supported, result is then equal to Not a Number (NaN). These results are marked with an invalid (IV) flag.
### Binary operations
Table. Supported binary operators:
| Operator | Description | Priority |
| =
| assignment
| -1 |
| »
| right shift
| 0 |
| «
| left shift
| 0 |
| &
| bitwise and
| 0 |
| |
| bitwise or
| 0 |
| &&
| logical and
| 1 |
| ||
| logical or
| 2 |
| <=
| less or equal
| 4 |
| >=
| greater or equal
| 4 |
| !=
| not equal
| 4 |
| ==
| equal
| 4 |
| > | greater than
| 4 |
| < | less than
| 4 |
| + | addition
| 5 |
| - | subtraction
| 5 |
| \* | multiplication
| 6 |
| / | division
| 6 |
| ^
| raise x to the power of y
| 7 |
Ternary operators can be used. This expression can be compared to the operator supported by C/C++ language (Table 39). Condition is written before a question (?) sign. If condition is true, result after question sign is selected. If condition is false, result after colon (:) is selected.
### Ternary operations
Table. Supported ternary operators
| Operator | Description | Remarks |
| ?:
| if then else operator
| C++ style syntax
|
### Examples
User can construct his own equation by using the aforementioned operators and functions. These examples can be seen in Table bellow.
Table. Example expressions
| Expression
| Description
|
| value \* 0.0001
| Multiply the tag by a constant.
|
| value + TagValue(”tag/dev\_alias/sig\_alias/out”)
| Add value of tag/dev\_alias/sig\_alias/out to the current tag.
|
| sin(value)
| Return a predefined sine function value of the tag.
|
| (value>5)? 1: 0
| If value is greater than 5, result should be equal to 1, otherwise - equal to 0
|
Variable called value is generated or updated on every signal change and represent the signals being configured. If another value from tag list is intended to be used, one should use `TagValue()` function to retrieve its last value.
The inner argument of `TagValue()` function has to described in a Redis topic structure of WCC Lite. That means that it has to be constructed in a certain way. Quotes should be used to feed the topic name value, otherwise expression evaluation will fail.
Every Redis topic name is constructed as tag/\[device\_alias\]/\[signal\_alias\]/\[direction\]. Prefix tag/ is always used before the rest of argument. `device_alias` and `signal_alias` represent columns in Excel configuration. direction can have one of four possible values - rout, out, in, rin; all of which depend on the direction data is sent or acquired device-wise. For example, out keyword marks data sent out of WCC Lite device, whereas in direction represents data that WCC Lite is waiting to receive, for example, commands. Additional r before either direction means that data is raw, it was is presented the way it was read by an individual protocol.
### Extra functions
Several functions are defined make tag operations possible:
- `TagValue(key)` - returns last known value of tag identified by redis key;
- `TagFlag(key)` - returns 1 if tag flag exists. Name format is: ”key flag”. For example to check if tag is notopical, name would be ”tag/19xxxxxxx/x/x nt”;
- `TagAttribute(key)` - similar to TagFlag, but returns a numeric value of a tag attribute;
- `TagTime(key)` - returns unix timestamp in milliseconds of a last know tag value.# 33.3 Uploading configuration
As of WCC Lite version v1.4.0 there are three separate ways to import the configuration: import an Excel file via web interface, generate compressed configuration files and later upload them via web interface; or generate compressed configuration files and upload them via utility application.
For WCC Lite versions v1.4.0, name of the file is shown in Protocol Hub->Configuration. Older versions only allow configuration file to be stored to a file called phub.xlsx and later downloaded with a custom-built name reflecting date of a download. Upgrade process from older version to versions v1.4.0 and above when preserving configuration files automatically makes the neccessary changes to enable this new functionality of WCC Lite.
If a user intends to **downgrade** firmware to versions older than version v1.4.0 from newer versions, he/she must first download the configuration files and later reupload the configuration after finishing the upgrade process.
### Importing an Excel file
Excel file can be imported without any external tools. This option can be used where there is no internet connection or only minor change has to be applied. This way of importing is not suitable for validation of Excel configuration file.
**Generating configuration is a resource-intensive task.** It might take up to 10 minutes depending on configuration complexity
Supported types of an Excel configuration: .xlsx, .xlsm, .xltm, .xltx
To upload an Excel file, open Protocol Hub->Configuration screen in Web interface, select Configuration file and press Import configuration.
### Generating .zip file
To accelerate a task of generating configuration a computer can be used. For this user should download WCC Excel Utility application. Upon opening an application, user should search for a field called Excel file which lets to choose an Excel file for which a conversion should be made. Output file should be filled out automatically, however, this value can be edited.
To make a conversion press Convert. If there are no errors found in the configuration, output file should contain the generated configuration, otherwise, error message is shown to a user.
This .zip file can be uploaded via Web interface, using the same tools as used for import of an Excel file.
### Uploading configuration remotely
As of WCC Lite version v1.4.0 generated configuration files can be uploaded by a click of button in the Excel Utility. There are four parameters (not counting the configuration file itself) that have to be filled in before starting upload:
- *Hostname*: an IP address for device to connect to. This field conforms to hostname rules, therefore, if invalid value is selected, it is reset to default (192.168.1.1);
- *Port*: a PORT number to which a SSH connection can be made; valid values fall into a range between 1 and 65535; if invalid value is selected, it is reset to default (22);
- *Username*: a username which is used to make a SSH connection; make sure this user has enough rights, preferably root;
- *Password*: a password of a user used for establishing a SSH connection;
Configuration can only be uploaded if a port used for SSH connection is open for IP address filled in hostname entry field. Please check WCC Lite firewall settings in case of connection failure.
To upload a configuration remotely, press Upload configuration. If no errors occur, you should finally be met with text output mentioning configuration has been applied. During the course of upload process the aforementioned button is disabled to prevent spanning multiple concurrent processes.# 34 Programmable logic controller
A programmable logic controller (PLC) is a digital device adapted for control of processes which require high reliability, ease of programming and realtime responses. Such functionality has long since replaced hardwired relays, timers and sequencers which would be required to complete various tasks.
Programmable logic controllers usually had to conform to IEC 611313 standard which defines four programming languages: function block diagram (FBD), ladder diagram (LD), structured text (ST) and sequential function chart (SFC). This standard does not support distributed control systems therefore IEC 61499 standard was published in 2005. The standard is considered an extension of IEC 611313 standard.
WCC Lite supports PLC functionality while conforming to specifications of IEC 61499 standard.
### IEC 61499
IEC 61499-1 defines the architecture for distributed systems. In IEC 61499 the cyclic execution model of IEC 61131 is replaced by an event driven execution model. The event driven execution model allows for an explicit specification of the execution order of function blocks. If necessary, periodically executed applications can be implemented by using the E\_CYCLE function block for the generation of periodic events.
IEC 61499 enables an application-centric design, in which one or more applications, defined by networks of interconnected function blocks, are created for the whole system and subsequently distributed to the available devices. All devices within a system are described within a device model. The topology of the system is reflected by the system model. The distribution of an application is described within the mapping model. Therefore, applications of a system are distributable but maintained together.
Like IEC 61131-3 function blocks, IEC 61499 function block types specify both an interface and an implementation. In contrast to IEC 61131-3, an IEC 61499 interface contains event inputs and outputs in addition to data inputs and outputs. Events can be associated with data inputs and outputs by WITH constraints. IEC 61499 defines several function block types, all of which can contain a behavior description in terms of service sequences:
Service interface function block – SIFB: The source code is hidden and its functionality is only described by service sequences;
• Basic function block - BFB: Its functionality is described in terms of an Execution Control Chart (ECC), which is similar to a state diagram (UML). Every state can have several actions. Each action references one or zero algorithms and one or zero events. Algorithms can be implemented as defined in compliant standards.
• Composite function block - CFB: Its functionality is defined by a function block network.
• Adapter interfaces: An adapter interface is not a real function block. It combines several events and data connections within one connection and provides an interface concept to separate specification and implementation.
• Subapplication: Its functionality is also defined as a function block network. In contrast to CFBs, subapplications can be distributed.
To maintain the applications on a device IEC 61499 provides a management model. The device manager maintains the lifecycle of any resource and manages the communication with the software tools (e.g., configuration tool, agent) via management commands.
### 4Diac framework
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601992021990.png)
The PLC functionality in the WCC Lite is implemented using Eclipse 4diac framework, consisting of the 4diac IDE and the 4diac FORTE runtime. The system corresponds to IEC 61499, an extension of IEC 61131-3. For more in-depth instructions and function block reference please see the 4diac manual - this document is merely a quick start guide that emphasizes the specifics of tailoring the applications to run on the WCC Lite.
The 4diac IDE application is used to model logic sequences. An output file, \*.fboot, is then generated and either loaded into the runtime for debugging purposes (functionality available from within the IDE), or uploaded into the controller for normal use via web interface.
During debugging, the output logic is executed directly in the runtime. Any logic loaded during debugging will be discarded after a reboot of the controller. Logic applications for regular use should be uploaded via the web interface.
It is possible to run multiple tasks at once. These tasks can either be implemented in the same screen or split into separate tasks. Please note, however, that all elements should have unique names, even between different tasks. As of 4diac IDE 1.11.3 this is not enforced between separate apps, however, 4Diac runtime application rejects such file purely because of naming issues.
The 4diac FORTE runtime is able to execute the aforementioned fboot files containing the logic. The FORTE runtime can be run on both the WCC Lite and a PC for debugging purposes. The runtime is integrated to interact with the REDIS database.
### Example project
The best way to understand basics of 4Diac and WCC Lite collaboration is through an example project. This user manual intends to show the pieces needed to run PLC applications on WCC Lite. It is not intended to be definitive guide on how to use 4Diac IDE or how to interpret IEC 61499 standard.
During (at least) the first start of the IDE user will be asked to select a directory for the workspace as in Figure. Workspace is used to save files needed for projects.
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601992159243.png)
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601992177394.png)
After that a user should be met by the welcome window as in Figure 20. If such window is not shown, one can create create project by selecting File->New->Project and filling in the required fields (figure 21).
To create a simple application, simply drag and drop objects from the palette to the canvas and wire them accordingly. Event trigger and data pathways cannot be connected to one another. Displayed below is an example of a simple blinker application (figure 22).
Having less wiring by connecting several signals to same subnet as PCB designer (such as Altium Designer) as of 4Diac IDE 1.11.3 is not supported. However, if some parts are used frequently, it is highly advised to have less wiring by simply compiling several elements into a subapplication. For this, you would have to select elements to be grouped, press right key and select New Subapplication. You can later change names of such elements and its pins.
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601992239152.png)
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601992245178.png)
In the System Configuration section, drag and drop a FORTE\_PC device, an Ethernet segment and link them (figure 23). For debugging in the local (PC) runtime, leave the address ”localhost:61499”. For testing on a WCC Lite, enter the IP address of the device, along with the port number (which by default is 61499 as well).
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601992273595.png)
In order to deploy the application, the circuit needs to be mapped to the controller. For a non-distributed application (distributed application cases will not be discussed in this chapter), all the FBs of the application need to be selected and mapped to the configured controller as shown in figure 24.
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601992299991.png)
To start the application execution, an initial trigger needs to be present. For a non-distributed application, the initial event trigger needs to be wired from the START function block in the resource section as shown in figure 25.
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601992323578.png)
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1601992330383.png)
To deploy the application, go to the System Configuration tab and simply select ”Deploy” from the right-click menu of the controller device (figure 26). If a running application exist in the runtime, you may be asked whether you want to replace it. This will only overwrite the application in the memory and not the storage. If the controller is restarted, the old application will be loaded from the
non-volatile memory of the controller.
### Configuring data endpoints
To use WCC Lite as a programmable logic controller, it needs to be configured in a particular way. The PLC functionality of the WCC Lite only allows for the use of data that is has been configured in the Excel configuration spreadsheet. This has been done for security purposes and to preserve transmission medium only for data that is available. Only topics defined in the configuration can post or get data. If a certain data entry exists but it has not been linked to a PLC program, all calls from PLC runtime application to Redis database will be ignored. Therefore it is highly advised to prepare and upload the Excel configuration before using this signal in the PLC application.
Some parameters are mandatory for PLC usage. These parameters are shown in two tables below (one for Devices, one for Signals tab). Please note that other parameters can be used as well, but are not covered because they aren’t specific to PLC functionality.
Table. Mandatory parameters for Devices tab
| Parameter | Type | Description |
| name
| string
| User-friendly device name
|
| device\_alias
| string
| Device alias to used in configuration
|
| enable
| boolean | Enabling/disabling of a device
|
| protocol
| string
| Selection of protocol (IEC 61499)
|
Table. Mandatory parameters for Signals tab
| Parameter | Type | Description |
| signal\_name
| string
| User-friendly signal name
|
| device\_alias
| string
| Device alias from a Devices tab
|
| signal\_alias
| string | Unique signal name to be used
|
| source\_device\_alias
| string
| device\_alias of a source device
|
| source\_signal\_alias
| string
| signal\_alias of a source signal
|
If an upload consisting of configuration for IEC 61499 has been succesful, one should be able to access a configuration stored in /etc/iec61499.json file where protocol-specific parameters are shown in a JSON format. If the file is missing, make sure you have a correct firmware version installed and haven’t made any typing errors.
Parameters mentioned earlier, namely device\_alias and signal\_alias, are the only parameters one needs to fill to bind Excel configuration to 4Diac framework. Two types of blocks are used for data transmission - PUBLISH blocks to write data to REDIS database and SUBSCRIBE blocks to acquire data from database as soon as it changes its value. Both of them have an ID connection. To connect a block to a datapoint, one should set this pin as raw\[\].redis\[device\_alias,signal\_alias\], e.g. raw\[\].redis\[example\_plc\_device,example\_plc\_signal\_alias\].
An example with SUBSCRIBE and PUBLISH function blocks is shown below in image below.
Subscribe and publish examples[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1602661793915.png)
Outputs of variable type ANY cannot be directly wired to inputs of the same type and therefore need to be explicitly typed using transitional function blocks
No more than 20 tags should be published over a period of 5 seconds, as this may overfill the queue. A ”publish only on change” policy is advised.
Currently only PUBLISH\_1 and SUBSCRIBE\_1 function blocks are supported.
If every step until now has been succesful, a user could now start debugging a PLC application.
### Debugging an IEC 61499 application
After a project has been built and binded to an existing Excel configuration, a user would normally want to check if every part is working according to the prior requirements before compiling finished project and uploading it to production. Both 4Diac framework and WCC Lite offer tools for flexible debugging.
There is a possibility that 4Diac FORTE might not start as a process. It may happen if multiple faults occured and process has stopped. Process is also programmed to not start if no excel configuration file is found, therefore a user should make sure that Excel configuration is uploaded and ready for use.
Individual function blocks can be set to Watch mode: events can be triggered and values can be forced at inputs or outputs (look into images bellow). To monitor the function blocks, the application should be deployed and the IDE should be in Online mode (Debug -> Monitor System -> NewSystem).
Selecting watch mode:
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1602662191072.png)
Function blocks in watch mode:
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1602662206569.png)
Seeing information dynamically updated on 4Diac IDE might be very informative, however, some applications might require accesing WCC Lite via command-line interface. For example, in case of information not being updated one would want to assure that 4Diac FORTE in WCC Lite is not filtering data out but sending it to internal database (Redis). To run 4Diac FORTE debug from command-line interface, a user should write forte and press Enter. All possible choices are shown by adding -h flag. More flags are shown in a Table bellow. Make sure to stop any running process that could use the address that 4Diac framework is going to use.
Table. 4Diac FORTE command line debugging options:
```
-h - Display help information
-c : - Set the listening IP and port for the incoming connections
-r - Show redis messages
-d - Set debugging level
-f - Set the boot-file where to read from to load the applications
```
### Generating and uploading FORTE logic file
After the PLC design is finished and debugged, such design can be compiled into FBOOT file and uploaded to one or multiple devices to be used in production. As application being debuggged is not automatically considered as a default application, one should be uploaded explicitly via web interface.
To generate FORTE boot-files a user should select Run->Create FORTE boot-file.... After that one should select devices which should have their boot files created as well as additional devices’ properties and directory where these files should be stored as in picture bellow.
Generating FBOOT file:[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1602662453356.png)
Upload button for FORTE file in web interface can be found in Protocol Hub tab, Configuration screen (FORTE boot file upload supported for versions v1.4.0 and above). You should see a view as in picture below.
WCC Lite Web interface. Upload and download of 4Diac configuration files:
[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1602662559336.png)
After the file has been imported one should be able to download it from the same screen as seen in the picture before.
Please note that only files with \*.fboot extension are allowed.
Uploading a file saves it's name and shows it in the web interface. It is advised to carefully choose a filename to separate different versions of PLC application files.
### Distributed control application
IEC 64199 standard introduced requirements for a distributed control. This means that multiple devices can change information between them and make their own decisions based on the data they receive from other sources. This enables distributed applications between multiple WCC Lite devices and all other devices that support IEC 61499.
Communication between devices can be configured using:
- Publish/Subscribe function blocks (via UDP packets);
- Client/Server function blocks (via TCP packets).
A Publish block can publish data messages using UDP multi-cast addresses meaning that multiple devices would be able to simultaneously get the same data. However, one would have to make sure that all of the devices support multi-cast option.
This user manual will only cover setting up point-to-point communication between devices via Publish/Subscribe blocks. For more information on communication between several IEC 61499 devices please check documentation for Eclipse 4diac framework.
Let’s say we would like to count how many times the light has been turned on. For this we can add counting functionality to application shown in picture below. The application should run on 2 devices. The blinking part of the application will run on a 4diac FORTE and the count on another 4diac FORTE, see the architecture below. The two different programs running on two separate WCC Lite devices emulate two PLCs. Two different devices can be identified by different colors of function blocks. One can identify device and it properties by accessing System Configuration screen as seen below. Yellow function blocks belong to WCC\_212 device which can be accessed through 192.168.4.212 (port number 61499) whereas brown function blocks belong to WCC\_218 device which can accessed through 192.168.4.212 (port number 61499).
Example blinking application as a distributed system:[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1602662769321.png)
Example system configuration for a distributed system:[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1602662862391.png)
Example app for blinking part of a distributed system:[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1602662875556.png)
Example app for counting part of a distributed system:[](https://wiki.elseta.com/uploads/images/gallery/2020-10/image-1602662888137.png)
To count the blinking, two new Function Blocks (FBs) have been added to the existing application for a different device (WCC\_218):
- E\_PERMIT
- E\_CTU
To communicate between devices, an additional PUBLISH\_X/SUBSCRIBE\_X pair must be used. As one can identify, these blocks are not seen when looking at a whole distributed system and should be seen as an intermediary between devices.
The PUBLISH\_X FB is used to send messages over the network which are received by an according SUBSCRIBE\_X FB. Every time a REQ is triggered, a message is sent according to the ID input. With the value of the ID input you can specify what specific network protocol you would like to use (e.g., MQTT). If you don’t specify a dedicated protocol the default as defined in the ”IEC 61499 Compliance Profile for Feasibility Demonstrations” is used. The number X in PUBLISH\_X is the number of data elements that you want to send in the message. Since we are only sending one value we used PUBLISH\_1.
The used ID value specifies an IP:PORT pair.# 35 MQTT
### Introduction
MQTT (short for MQ Telemetry Transport) is an open OASIS and ISO standard (ISO/IEC PRF 20922) lightweight, publish-subscribe network protocol that transports messages between devices. The protocol usually runs over TCP/IP, although its variant, MQTT-SN, is used over other transports such as UDP or Bluetooth. It is designed for connections with remote locations where a small code footprint is required or the network bandwidth is limited.
The broker acts as a post office, MQTT doesn’t use the address of the intended recipient but uses the subject line called “Topic”, and anyone who wants a copy of that message will subscribe to that topic. Multiple clients can receive the message from a single broker (one to many capability). Similarly, multiple publishers can publish topics to a single subscriber (many to one).
Each client can both produce and receive data by both publishing and subscribing, i.e. the devices can publish sensor data and still be able to receive the configuration information or control commands. This helps in both sharing data, managing and controlling devices.
With MQTT broker architecture the devices and application becomes decoupled and more secure. MQTT might use Transport Layer Security (TLS) encryption with user name, password protected connections, and optional certifications that requires clients to provide a certificate file that matches with the server’s. The clients are unaware of each others IP address.
The broker can store the data in the form of retained messages so that new subscribers to the topic can get the last value straight away.
The main advantages of MQTT broker are:
- Eliminates vulnerable and insecure client connections
- Can easily scale from a single device to thousands
- Manages and tracks all client connection states, including security credentials and certificates
- Reduced network strain without compromising the security (cellular or satellite network)
Each connection to the broker can specify a quality of service measure. These are classified in increasing order of overhead:
- At most once - the message is sent only once and the client and broker take no additional steps to acknowledge delivery (fire and forget).
- At least once - the message is re-tried by the sender multiple times until acknowledgement is received (acknowledged delivery).
- Exactly once - the sender and receiver engage in a two-level handshake to ensure only one copy of the message is received (assured delivery).
WCC Lite supports MQTT messaging compatible with MQTT v3.1 standard (starting from version **v1.4.0**). Such messaging is possible via mapping of Redis and MQTT data therefore data can be transmitted from any protocol that is supported by WCC Lite.
All standard functions, except for data encryption, are supported. Encrypted messages are not supported yet, therefore to ensure security a user would have to use a VPN service. A user can choose from three different Quality of Service levels, select if messages are to be retained, authenticate users and optionally send Last Will messages.
To configure WCC Lite a user can fill in the needed parameters in Excel configuration. These parameters are shown in two tables below.
Table. MQTT parameters for Devices tab
| **Parameter**
| **Type**
| **Description**
| **Required
| **Default value**
(when not specified)
| **Range**
|
| Min
| Max
|
| name | string
| User-friendly device name
| Yes | | | |
| device\_alias | string
| Device alias to used in configuration
| Yes | | | |
| enable | boolean | Enabling/disabling of a device
| No | 0 | 0 | 1 |
| protocol | string
| Selection of protocol
| Yes | | MQTT |
| host | string
| MQTT broker IP address selection
| Yes | | | |
| port | integer | MQTT broker port selection
| No | 1883 | | |
| enable\_threshold | boolean | A parameter to determine if identical values should not be sent multiple times in a row.
| No | 1 | 0 | 1 |
| gi\_interval\_sec | integer | Parameter to determine how frequently should all values be sent at once. Disabled if equal to 0.
| No | 0 | | |
| mqtt\_qos | integer | MQTT Quality of Service for message as in standard
| No | 0 | 0 | 2 |
| mqtt\_retain | boolean | Selecting if MQTT broker should retain last received messages
| No | 0 | 0 | 1 |
| user | string
| MQTT user name
| Yes | | | |
| password | string
| MQTT user password | Yes | | | |
| use\_last\_will | boolean | Selecting if MQTT should use Last Will and Testament functionality
(Default: False)
| No | 0 | 0 | 1 |
| last\_will\_topic | string
| Topic to which an MQTT message would be sent if the device abruptly disconnected message broker
| Yes
(If use\_last\_will=True)
| | | |
| last\_will\_message | string
| Message to be sent over MQTT if the device abruptly disconnected message broker
| No | | | |
| last\_will\_qos
| integer | MQTT Quality of Service selection as in standard
| No | 0 | | |
| last\_will\_retain
| boolean | Selecting if MQTT broker should retain last will message
| No | 0 | 0 | 1 |
To map the signal to send through MQTT client, it should have its device\_alias and signal\_alias mapped to source\_device\_alias and source\_signal\_alias respectively.
If MQTT is configured but does not send data, a user can use command line interface to debug transmission. All options for MQTT process which transmits data over MQTT (called mqtt-client as it
Table. MQTT parameters for Signals tab
| **Parameter**
| **Type**
| **Description**
| **Required
| **Default value**
(when not specified)
| **Range**
|
| Min
| Max
|
| signal\_name | string | User-friendly signal name
| Yes | | | |
| device\_alias | string | Device alias from a Devices tab
| Yes | | | |
| signal\_alias | string | Unique signal name to be used
| Yes | | | |
| source\_device\_alias | string | device\_alias of a source device
| No | | | |
| source\_signal\_alias | string | signal\_alias of a source signal
| No | | | |
| enable | boolean | Enabling/disabling of an individual signal
| No | 1 | 0 | 1 |
| log | integer | Allow signal to be logged. Log signal with 1 and no logging with 0.
| No | 0 | | |
| topic | string | Topic name to override the value built by default
| No | | | |
### MQTT data format
The format of a MQTT message is a bit different than Redis messages. Redis messages are supported as CSV strings: value,timeStamp,flags (where value can be float, integer or nan; timeStamp - Unix timestamp in milliseconds; flags contain additional information about a measurement). MQTT messages are supported as value,timestamp,quality (where value can be float, integer or nan; timeStamp - Unix timestamp in milliseconds; quality shows if a value is to be considered as valid). Quality parts of a string is always equal to 1 except for Redis messages containing invalid (IV), non-topic (NT) and/or overflow (OV) flags.
As mentioned, MQTT client acts as an adapter between Redis and MQTT, therefore data from topic in Redis is written to a topic in MQTT. Therefore mqtt-client has to know the mapping table before starting. This table is saved at /etc/elseta-mqtt.json. Every Redis topic name is constructed as tag/\[device\_alias\]/\[signal\_alias\]/\[direction\]. Prefix tag/ is always used before the rest of argument. `device_alias` and `signal_alias` represent columns in Excel configuration. Direction can have one of four possible values - rout, out, in, rin; all of which depend on the direction data is sent or acquired protocol-wise. The same Redis topic structure is preserved in MQTT by default making it easier to find matching signals, however, as no recalculation is done by MQTT and only PUBLISH messages are now supported, only Redis signals with in direction have their MQTT mappings.
A user can create and select his own topic name in Excel configuration, in topic column. As no recalculation is done by MQTT and only PUBLISH messages are now supported, only Redis signals with in direction have their MQTT mappings.
### Debugging a MQTT protocol
If configuration for MQTT is set up, handler for protocol will start automatically. If configuration is missing or contains errors, protocol will not start. It is done intentionally to decrease unnecessary memory usage.
MQTT Client command line debugging options
`mqtt-client`
```
-h [ –help ] Display help information
-c [ –config ] Configuration file location (default - /etc/elseta-mqtt.conf)
-V [ –version ] Show version
-d [ –debug ] Set debugging level
-r [ –redis ] Show REDIS output
-m [ –mqtt ] Show MQTT output
```
If MQTT Client does not work properly (e.g. no communication between devices, data is corrupted, etc.), a user can launch a debug session from command line interface and find out why link is not functioning properly.
To launch a debugging session, a user should stop `mqtt-client` process and run `mqtt-client` command with respective flags as was shown above.
# 36 Data Export
## General
Various protocols are made to transmit data points as they are generated. This is enough for a lot of systems (e.g. SCADAs) that have their own databases and devices only have to buffer fairly recent messages in case of connection or transmission errors. However, there is frequently a need to save and keep the data in files, grouped in batches, and later transmit these batches to a remote server via HTTP(S) or FTP(S). For this purpose a dedicated protocol has been created and called **Data export.**
Data export functionality is available since firmware version v1.5.0, of WCC Lite.
## Overview
Data export service gathers information from other protocols, puts it into files (optionally compressing them) after a timeout or when data buffers fill up; eventually periodically sending them to a server. HTTP(S) and FTP(S) servers with optional authentication are supported. A user can optionally choose between ISO8601 and UNIX timestamp time formats (the latter being the default value). More than one instance can set up, for instance, some of the information can be sent to an FTP server, while other could be transmitted to the HTTP server which is able to handle POST requests.
## Using WCC Lite for data export
To configure WCC Lite to use data export server a user can fill in the needed parameters in Excel configuration. These parameters are shown in two tables below. Default values are shown in a bold font.
*Data export (data-export) parameters for Devices tab table:*
| **Parameter**
| **Type**
| **Description**
| **Required
| **Default value**
(when not specified)
| **Range**
|
| Min
| Max
|
| name | string | User-friendly device name
| Yes |
|
|
|
| device\_alias | string | Device alias to be used in configuration
| Yes |
|
|
|
| enable | boolean | Enabling/disabling of a device
| No | 1 | 0 | 1 |
| protocol | string | Selection of protocol
| Yes |
| Data Export |
| timeout | integer | Time frame during which transmission to remote server has to be completed (**in seconds**)
| No | 5 |
|
|
| type | string | Selection of file format
| No | csv-simple | csv-simple,
csv-periodic,
json-simple,
json-samples
|
| host | string | A URL of remote server where files should be sent
| Yes |
|
|
|
| upload\_rate\_sec
| integer | Frequency of generated file uploads (**in seconds)**
| No | 60 |
|
|
| records\_buffer\_size
| integer | A maximum amount of data change entries to hold before initiating logging mechanism
| No | 100 |
|
|
| logging\_period\_sec
| integer | Describes how frequently data buffer of records\_buffer\_size is saved to file
| No |
| 1 |
|
| log\_folder
| string | A folder in WCC Lite file system to save generated file (**”/var/cache/data-export”**)
| No |
|
|
|
| timestamp
| string | Selection of time format
| No |
| unixtimestamp, iso8601 |
| compress
| string | Selection of file compression mechanism
| No | none | none, gz, tar.gz |
| compress\_password
| string | Enable feature of file password protection
| No |
| yes, true |
| csv\_field\_separator
| string | Columns separator in .csv file format
| No | "," - (comma) | "," - (comma)
";" - (dot)
"." - (semicolon)
" " - whitespace)
"|" - (pipe)
|
| csv\_decimal\_separator
| string | Decimal separator in values
| No | "." - (dot) | "." - (dot)
"," - (comma)
|
Same symbols cannot be selected for both csv\_field\_separator and csv\_decimal\_separator. In such case both of them will be set to default values ”.” and ”,” respectively.
It is possible that data generation rate is going to be bigger than what data buffer can hold (controlled by *records\_buffer\_size* and *logging\_period\_sec*). To make sure that no data loss occurs there’s an additional data logging call made in case data buffer reaches a *records\_buffer\_size* value.
Signals to be sent are configured differently than signals for most other protocols. As data export service only transmits signals and does no data processing, usual signal logic is not used for them. That means that:
• Signals for data export service are not seen in the *Imported Signals* tab;
• Signals for data export service are configured in different Excel sheet called DataExport
Parameters to be filled in the DataExport sheet are shown in a table below.
*Data export (data-export) parameters for DataExport tab*
| **Parameter**
| **Type**
| **Description**
| **Required
| **Default value**
(when not specified)
| **Range**
|
| Min
| Max
|
| device\_alias
| string | Device alias to be used in configuration Yes
| Yes |
|
|
|
| device\_name
| string | User friendly device name as in Device sheet
| Yes |
|
|
|
| tag\_name | string | User friendly signal name
| Yes |
|
|
|
| source\_device\_alias | string | device\_alias of a source device
| Yes |
|
|
|
| source\_signal\_alias | string | source\_alias of a source signa
| Yes |
|
|
|
| enable | boolean | Enabling/disabling of a measurement to be transmitted and logged
| No | 1 | 0 | 1 |
| attribute | string | Additional attribute to be attached to a signal
| No |
|
|
|
## Debugging data export service
If configuration for Data export service is set up, handler for protocol will start automatically. If configuration is missing or contains errors, protocol will not start. It is done intentionally to decrease unnecessary memory usage.
Data export (data-export) command-line debugging options
The below-described parameters for debugging are accessible over console (SSH).
`-h [--help] Display help information`
`-c [--config] Configuration file location`
`-V [ –version ] Show version`
`-d [ –debug ] Set debugging level`
`-R [ –readyfile] Ready notification file`
`-p [ –http ] Show HTTP messages`
`-r [ –redis ] Show Redis output`
If Data export service does not work properly (e.g. data is corrupted, etc.), a user can launch a debug session from command line interface and find out why it is not functioning properly. To launch a debugging session, a user should stop data-export processes and run data-export command with respective flags as in table above.
## Host URL format rules
Parameter host is highly configurable and might contain a considerable amount of information:
• *Protocol* - FTP or HTTP (encrypted and encrypted);
• *URL address* - both resolved and non-resolved;
• *Authentication* - pair of user and/or password;
• *Port* - useful when non-standard value is used;
• *Endpoint* - a place in server to which a call is made
The format for host parameter can be summarized as:
`[ h t t p ( s ) / f t p ( s ) ] : / / [ [ u s e r ] : [ p a s s w o r d ]@] [ URL ] [ : p o r t ] / [ e n d p o i n t ]`
Options are printed in square brackets. A protocol has to be selected, otherwise HTTP will be used as a default. User and password pair is optional, but if user:password pair is used, it should proceeded with @ sign.
HTTP and FTP use default or user assigned ports. By default HTTP uses port 80, while HTTPS uses port 443, FTP sends data over port 21, FTPS - over port 990. Make sure that these ports are open in firewall on both server and client side, otherwise data will not be sent succesfully.
Finally, POST request (for HTTP) or upload (for FTP) can be made to a specific place (endpoint). This endpoint should be described after a URL and port (if used).
## Format of exported data
For a server to interpret data, a set of rules for a file format have to be established.
***Csv-simple*** format applies to all files by default and is used as in this example:
```
###DUID:3182121xx
#device name; tag name; value; quality; timestamp; atribute
inv1;Ia;236.9,1;1599137189963;Pa
```
Example of additional format *csv-periodic:*
```
###DUID:318212xxx
##DEVICE:inv1
#Time;Upv1;Upv2;Upv3;Upv4;Upv5;Upv6;Ipv1;Ipv2;Ipv3;Ipv4;Ipv5;Ipv6;Status;Error;Temp;cos;fac;Pac;Qac;Eac;E-Day;E-Total;Cycle Time
2020-09-02T15:45:00Z;462.3;462.3;370.2;370.2;371.2;371.2;1.40;1.43;1.35;1.47;1.21;1.26;512;0;26.3;1.000;50.00;3.217;-0.029;0.28;17.41;54284.53;5;
2020-09-02T15:40:00Z;462.3;462.3;370.2;370.2;371.2;371.2;1.40;1.43;1.35;1.47;1.21;1.26;;512;0;26.3;1.000;50.00;3.217;-0.029;0.28;17.41;54284.53;5;
##DEVICE:meter
#Time;Uab;Ubc;Uca;P;Q;S;F;eTOT;Cycle Time
2020-09-02T15:45:00Z;421.3;421.3;421.3;15000;100;15600;50;246894;5;
2020-09-02T15:40:00Z;421.3;421.3;421.3;15000;100;15600;50;246895;5;
```
Example of additional format json-simple*:*
```
{
"metadata": {
"duid": "318xxxxx",
"name": "hostname",
"loggingPeriod": "15min",
"format": "json"
},
"data": [
{
"tag_name": "Ia",
"device_name": "inv1",
"attribute": "Pa",
"last": { "value": 12.2, "timestamp": 1213123 },
"min": { "value": 12, "timestamp": 1213123 },
"max": { "value": 12, "timestamp": 1213123 },
"avg": { "value": 12, "timestamp": 1213123 }
},
{
"tagName": "Ib",
"deviceName": "inv1",
"attribute": "Pb",
"last": { "value": -12.3, "timestamp": 1213123 },
"min": { "value": 12, "timestamp": 1213123 },
"max": { "value": 12, "timestamp": 1213123 },
"avg": { "value": 12, "timestamp": 1213123 }
},
]
}
```
Example of additional format json-sample*:*
```
{
"metadata": {
"duid": "318xxxxx",
"name": "hostname",
"loggingPeriod": "15min",
"format": "json-samples"
},
"data": [
{
"tag_name": "Ia",
"device_name": "inv1",
"attribute": "Pa",
"timestamp":{
"first": 123123,
"last": 123236
},
"first": { "value": 12.2, "timestamp": 1213123 },
"last": { "value": 12.2, "timestamp": 1213123 },
"min": { "value": -12, "timestamp": 1213123 },
"max": { "value": 12, "timestamp": 1213123 },
"avg": { "value": 12, "timestamp": 1213123 },
"samplesCount": 2,
"samples": [
{"value": 12, "timestamp": 1213123, "quality": true},
{"value": -12.3, "timestamp": 1213123, "quality": true}
]
}
]
}
```# 37 Certificates
Devices that send unencrypted data are susceptible to attacks which might cause deliberate damage to the user system. Therefore it is highly advised to use cryptography to secure the sensitive data. WCC Lite offers means to easily store certificates for their later usage.
Some protocols, namely IEC60870-5-104 Slave, DNP v3.0 Slave and Master might be configured to send data over TCP/IP. For these protocols, secured connection over TCP/IP using TLS certificates can be made. For this purpose, certificate storage has been created and is available since firmware version 1.3.0.
To make storage secure, multiple steps have been taken:
- By default certificate storage is only accessible for root user and users with group level 15
permissions;
- By default certificates are not added to backup to avoid private key leakages; private keys
should never be revealed to public;
- By default certificates are deleted after system upgrade;
- Only basic information is shown on a web interface; certificates can be uploaded, deleted but
not downloaded
Certificates can be split into three parts local (private) certificate, certificate from peer (usually called Certificate Authority (CA)) and private key. It has to be noted that all of these certificates sometimes can be found in one file, therefore ideally a user should have at least minimal understanding about formats in which certificates are stored.
Certificates should conform to the X509 standard. The difference between local certificate and certificate authority certificates is that only certificate authority generates certificates for others. Therefore Issuer and Subject fields are always the same for certificate authority certificate whereas they differ for local certificates. Both of these certificates are usually stored in a device to validate if incoming connections have valid certificates and are to be trusted. Both of the certificates have the public key which together with public key enable having encrypted connections.
The private key is a text file used initially to generate a Certificate Signing Request (CSR), and later to secure and verify connections using the certificate created per that request. It usually contains a unique hash made in a way that chances of guessing it by using brute force are technically infeasible. The private key should be closely guarded, since anyone with access to it use it in nefarious ways. If you lose your private key, or believe it was compromised in any way, it is recommended to rekey your certificate – reissue it with a new private key.
To make certificate upload more intuitive, certain restrictions are imposed. Only files with certain extensions (\*.crt, \*.pem, \*.der, \*.key) can be uploaded. Trying to upload other files will result in an error message. Certificate storage should be considered a folder with certain access restrictions, therefore file names should be unique for every file
It should be noted that this chapter only reviews main certificates and suggest means to use them for Protocol Hub services. Certificates can also be used for other causes, e.g. to secure VPN connections. For the sake of simplicity, uploading certificates and their usage are explained in their respective chapters where applicable.
Interface for certificate storage
[](https://wiki.elseta.com/uploads/images/gallery/2021-12/image-1638366685126.png)
To get more details about how one could use TLS for Protocol Hub protocols please check section Excel configuration format.
To find out more about why certificates help keep device secure please check section Cyber security or check X.509 and RFC 5755 standard.# 38 Cyber security
WCC Lite is based on OpenWRT operating system. OpenWrt is described as a Linux distribution for embedded devices. WCC Lite has same functionality as Linux OS including user management.
Basic configuration on WCC Lite can be done using web based frontend. More advanced configuration is available over terminal interface. For secure web access, WCC Lite can be accessed via HTTPS (TLS) instead of the unencrypted HTTP protocol. You can use openssl utility to generate your own certificate authority and certificates to be used on web interface. Certificates can also be named or placed in whatever directory you wish by editing /etc/lighttpd/lighttpd.conf.
Terminal is accessible over Telnet or SSH. For security reasons we strongly recommend to use SSH. SSH, also known as Secure Socket Shell, is a network protocol that provides administrators with a secure way to access a remote computer. SSH also refers to the suite of utilities that implement the protocol. Secure shell provides strong authentication and secure encrypted data communications between two computers connecting over an insecure network such as the Internet. SSH is widely used by network administrators for managing systems and applications remotely, allowing them to log in to another computer over a network, execute commands and move files from one computer to another.
### User rights
Depending on the user name, different rights are defined: admin is generally entitled to make changes while user does not have any editing permissions, the relevant buttons are disabled. User can be assigned to one of fifteen user groups that can access different amounts of device parameters. Highest (fifteenth) permision level grants the same permission as root user has. User group rights can be edited to give more rights or restrictions, except for highest (15th) level.
#### User management and rights authentication
WCC Lite provides different authentication mechanisms:
- Authentication via locally stored credentials. In this scenario all users, passwords and
permissions are encrypted and stored in internal WCC Lite storage.
- Authentication via external RADIUS Server. In this scenario all users, passwords and
permissions (profiles) are defined in remote RADIUS Server. Login into WCC Lite is available
only if RADIUS Server will grant authentication and will provide user profile with user rights on
that device (more detailed description below). This also means that a password for such user
cannot be changed remotely.
- Authentication via external RADIUS Server with fallback option. In this scenario users will be
authenticated via RADIUS server. If server fails to respond (configured timeout is passed) WCC
will use locally stored credentials. Fallback options are selected with PAM configuration.
By default only authentication via locally stored credentials is allowed. For authentication via external RADIUS server a user should at first enable RADIUS process and configure at least one server.
#### Locally stored credentials management
Device has predefined default users like *root* and *user.*
*Screen containing all users*
[](https://wiki.elseta.com/uploads/images/gallery/2021-12/image-1638367451931.png)
Screen for new user configuration
[](https://wiki.elseta.com/uploads/images/gallery/2021-12/image-1638367486607.png)
**root** user has full permission set to connect to WCC Lite over web interface and SSH or Telnet. This user is default user on WCC Lite and cannot be deleted. However, it is highly advised to change the default password to a different one less susceptible for attacks.
**user** is limited user on system and can’t get root rights. A default password for access via commandline interface and web interface is wcclite. It is advised to change this password to increase a level of security.
System allows customer to set up even more users with well known commands like *adduser, passwd* and *userdel.* More users can also be added or edited via web interface as shown in the figures above. User should enter user name, user groups for which the user should belong (the group must be preconfigured first), SSH access permision as well as password. When editing user settings, only *User Group* and *SSH Access* permission can be changed. To change user password, *Change Password* button should be pressed as seen in figure above to lead user to a screen seen in the figure below.
Changing user password
[](https://wiki.elseta.com/uploads/images/gallery/2021-12/image-1638367819194.png)
A user needs to be assigned to **root** group for admin rights and have root access
It should be noted that assigning user to a root group only gives complete authority over web interface. Permissions for a commandline interface should be given by a root user via commandline interface.
Following commands may be used in comamnd line interface for user control:
**adduser** - create a new user or update default new user information
When invoked without the **-D** option, the *adduser* command creates a new user account using the values specified on the command line plus the default values from the system. Depending on command line options, the useradd command will update system files and may also create the new user’s home directory and copy initial files.
**passwd** - change user password
The *passwd* command changes passwords for user accounts. A normal user may only change the password for his/her own account, while the superuser may change the password for any account. *passwd* also changes the account or associated password validity period.
**deluser** - delete a user account and related files
The *deluser* command modifies the system account files, deleting all entries that refer to the user name LOGIN. The named user must exist.
If a user intends to use newly created user account via both commandline interface and web interface he should create and delete users via web interface and not using adduser and deluser commands as they don’t create uci entries.
For more information about controlling users via command line interface one should refer to Linux documentation
#### Authentication via external service
WCC Lite support external authentification via RADIUS service. Remote Authentication DialIn User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA or Triple A) management for users who connect and use a network service. RADIUS is a client/server protocol that runs in the application layer, and can use either TCP or UDP as transport. Network access servers, the gateways that control access to a network, usually contain a RADIUS client component that communicates with the RADIUS server. RADIUS is often the backend of choice for 802.1X authentication as well. The RADIUS server is usually a background process running on a UNIX or Microsoft Windows server. In WCC Lite RADIUS Client is implemented since WCC Lite software version v1.2.4. The user sends a request to a WCC Lite to gain access to get access using access credentials posted in an HTTP/HTTPS WCCLite web login form
This request includes access credentials, typically in the form of username and password. Additionally, the request may contain other information which the Device knows about the user, such as its network address or information regarding the user’s physical point of attachment to the device. The RADIUS server checks that the information is correct using authentication schemes such as PAP, CHAP or EAP. The user’s proof of identification is verified, along with, optionally, other information related to the request, such as the user’s network address, account status, and specific network service access privileges. Historically, RADIUS servers checked the user’s information against a locally stored flat file database. Modern RADIUS servers can do this, or can refer to external sources—commonly SQL, Kerberos, LDAP, or Active Directory servers—to verify the user’s credentials. The RADIUS server then returns one of two responses to the WCC Lite:
1. **Access-Reject** - The user is unconditionally denied access to all requested resources. Reasons may include failure to provide proof of identification or an unknown or inactive user account.
2. **Access-Accept** - The user is granted access. Once the user is authenticated, the RADIUS server will periodically check if the user is authorized to use the service requested. A given user may be allowed to get admin rights or user rights depending on permissions set on RADIUS Server. Again, this information may be stored locally on the RADIUS server, or may be looked up in an external source such as LDAP or Active Directory.
To use this mechanism a RADIUS server must be configured. The parameter Radius Authentication must be Enabled on WCC Lite.
As of firmware version 1.2.13, the RADIUS service is disabled by default. The service can be enabled at System->Startup.
If the RADIUS authentication is enabled, WCC Lite uses the RADIUS server IP address and the RADIUS shared secret key for communication with External RADIUS Server. After entering the login credentials and login attempt, WCC Lite sends these credentials to the RADIUS server for authentication. If the RADIUS server is available, it compares the login credentials:
- If the comparison is successful, the RADIUS server returns the specific user role and Access-Accept;
- If the login credentials are invalid, Radius Server returns Access-Reject and the logon fails.
- If the RADIUS server is not available and fallback option is disabled login into WCC Lite will
be imposible. If RADIUS server is not available and timeout occurs, login will be attempted via
local login credentials.
*Enabled:* Enables or disables this server.
*Hostname/IP:* Hostname or IP address of RADIUS server.
*Timeout:* Timeout in seconds to wait for server response.
*Shared* secret: Key shared between RADIUS server and RADIUS client.
*Add:* Adds auxiliary (backup) server.
#### Audit Log
WCC Lite OS with version >1.2.0 has integrated Audit logging for important events such as:
- Login/logout.
- Wrong password attempts to login into system.
- Device boot event, when system was started.
- Device reboot/halt event.
- Configuration changes.
- Firmware changes.
- Date and time changes in system (excluding automatic system time updates over NTP or IEC 60870510x protocol)
Enabling external system log server setup in System properties > Logging is recomended. System stores logs in RAM memory by default due to limited flash storage. Rebooting or powering off the device will result in loss of log history.
#### Secure your device’s access
There are some possibilities to grant access to the device (or to any PC/Server):
1. ask for nothing: anybody who can establish a connection gets access
2. ask for username and password on an unsecured connection (e.g. telnet)
3. ask for username and password on an encrypted connection (e.g. SSH) (e.g. by following
firstlogin)
4. ask for username and merely a signature instead of a password (e.g. SSH with
signature.authentication)
If you ask for username/password, an attacker has to guess the combination. If you use an unencrypted connection, he could eavesdrop on you and obtain them.
If you use an encrypted connection, any eavesdropper would have to decrypt the packets first. This is always possible. How long it takes to decrypt the content, depends on the algorithm and key length you used.
Also, as long as an attacker has network access to the console, he can always run a bruteforce attack to find out username and password. He does not have to do that himself: he can let his computer(s) do the guessing. To render this option improbable or even impossible you can:
- not offer access from the Internet at all, or restrict it to certain IP addresses or IP address ranges
- by letting the SSH server dropbear and the webServer lighttpd not listen on theexternal/WAN port
- by blocking incoming connections to those ports (TCP 22, 80 and 443 by default) in yourfirewall
- make it more difficult to guess:
- don’t use the username root
- don’t use a weak password with 8 or less characters
- don’t let the SSH server dropbear listen on the default port (22)
- use the combination of:
- username different than root
- tell dropbear to listen on a random port (should be >1024): **System > Administration >Dropbear Instance > Port**
- public key authentication. Your public keys can be specified in **Administation > System > SSHkeys**. An older guide to DropBear SSH public key authentication has detailed information on generating SSH keypairs which include the public key(s) you should upload to your configuration.
### Groups rights
1.
If user is logged on via external server, its authentification level is acquired. As no direct mapping to existing users is used, authentification levels are a way to grant proper permissions for external users. WCC Lite uses a CISCOlike authentification system, meaning that there are fifteen different permission set level settings, of which the first 14 can be configured to enable or disable View and Edit permissions
#### SSH Access
SSH Access of WCC Lite is made by Dropbear software package. To extend the basic functionality, Pluggable Authentification Module (PAM) for RADIUS is used. This enables user to add his own authentification modules as long as they are properly configured.
Fifteen levels of authorization are mapped for SSH access, meaning that user should be able to access SSH with credentials used to log into web interface. However, one should note that permissions in command line interface are not configurable via web interface. This means that first fourteen levels are restricted to basic permissions made my creating group by default. Highest level
user has all the permissions root user has.
If a user intends to change permissions for user groups, it should be done via command line interfaces. It is only advised for advanced users.
#### Web interface permissions
Fifteen levels of authorization permission are mapped for web interface access, meaning that user should be able to access web interface with credentials used to log into command line interface. User assigned to a highest authorization level group is able to access every possible screen therefore this groups cannot be edited.
Figure below shows a screen containing already existing groups in a device. Pressing *Add New Group...* guides user to an *Edit group* screen, with *Edit* and *Delete* buttons respectively user can Edit and Delete configuration of a given user group.
Screen showing existing user groups
[](https://wiki.elseta.com/uploads/images/gallery/2021-12/image-1638369614131.png)
Screen for user group editing
[](https://wiki.elseta.com/uploads/images/gallery/2021-12/image-1638369707688.png)
Edit group screen for an individual group can be seen in Figure above. Group name doesn’t have any specific purpose for RADIUS, but it enables naming groups with words most meaningful for a given context. Access level values can only be integers between 1 and 14, other values will result in an error messages; only unconfigured levels are shown in a dropdown list when configuring. Other fields are dedicated for an individual menu configuration. To add more first level menus user should select from a dropdown list at the bottom named *–Additional Field–* and press Add.
Permissions for web interface are split into to parts: *View* and *Edit.*
*View* permissions can be assigned to second level menus meaning that only allowed subtabs are shown for a user. Selecting *View* checkbox show more parameters containing all the subtabs (submenus). If a user can access a given screen, it means all of the actions in that screen are available to be executed. Therefore, if a user with a lot of restrictions shouldn’t, for example, import Excel configuration to WCC Lite, a tab containing this action (*Protocol Hub>Configuration*) should be disabled in his groups' configuration.
*Edit* permissions can be assigned to first level menus meaning that if this permission is given, every configuration in the first level menu can be saved and applied succesfully
### Conformance to IEC 62351 standard
IEC 62351 is a standard developed by WG15 of IEC TC57. This is developed for handling the security of TC 57 series of protocols including IEC 608705 series, IEC 608706 series, IEC 61850 series, IEC 61970 series and IEC 61968 series. The different security objectives include authentication of data transfer through digital signatures, ensuring only authenticated access, prevention of
eavesdropping, prevention of playback and spoofing, and intrusion detection.
Conformance to IEC 62351 standard of WCC Lite devices is described in a table below.
Conformance to IEC 62351 standard
| **Standard** | **Description** | **Topic** | **Implemented** | **Version** |
| IEC 62351-3
| Security for any profiles including TCP/IP | TLS Encryption | Yes | >=1.3 |
| Node Authentication by means of X.509 certificates | Yes | >=1.3 |
| Message Authentication | Yes | >=1.3 |
| IEC 62351-4 | Security for any
profiles including
MMS | Authentication for MMS | Yes | >=1.5 |
| | TLS (RFC 2246)is inserted between RFC 1006 & RFC 793 to provide transport layer
security | Yes | >=1.5 |
| IEC 62351-5 | Security for any
profiles including
IEC 608705 | TLS for TCP/IP profiles and encryption for serial profiles | No | |
| IEC 62351-6 | Security for IEC
61850 profiles | VLAN use is made as mandatory for GOOSE | No | |
| RFC 2030 to be used for SNTP | No | |
| IEC 62351-7 | Security through
network and system
management | Defines Management Information Base (MIBs) that are specific for the power industry, to handle network and system
management through SNMP based methods | No | |
| IEC 62351-8 | Role-based access control | Covers the access control of users and automated agents to data objects in power systems by means of rolebased access
control (RBAC) | Yes | >=1.2.6 |
| IEC 62351-9 | Key
Management | Describes the correct and safe usage of safety-critical parameters, e.g. passwords,
encryption keys. | No | |
| Covers the whole life cycle of cryptographic information (enrolment, creation,
distribution, installation, usage, storage and removal) | No | |
| Methods for algorithms using asymmetric cryptography | No | |
| A secure distribution mechanism based on GDOI and the IKEv2 protocol is
presented for the usage of symmetric keys, e.g. session keys | No | |
| IEC 62351-10 | Security Architecture | Explanation of security architectures for the entire IT infrastructure | No | |
| Identifying critical points of the communication architecture, e.g. substation control center, substation automation | No | |
| Appropriate mechanisms security requirements, e.g. data encryption, user authentication | No | |
| Applicability of wellproven standards from the IT domain, e.g. VPN tunnel, secure FTP,
HTTPS | No | |
| IEC 62351-11 | Security for XML Files | Embedding of the original XML content into an XML container | No | |
| Date of issue and access control for XML data | No | |
| X.509 signature for authenticity of XML data | No | |
| Optional data encryption | No | |