The non-functional view is an overview of the most significant non-functional demands.

The identified non-functional demands are:

• Time Behavior

• Extensibility

• Internationalisation and localisation

• Security

• Scalability

The platform and devices use UTC time. The OSLP protocol between platform and devices uses UTC time as well.

Time behavior is mainly important in the Flexovl application when a lot of devices have to be addressed in a short period of time over a wireless network. Both latency and limited bandwidth have to be taken into consideration while demanding the coordinated on and off switching of the lighting, since we want to avoid the Christmas tree effect.

• Time synchronization: devices periodically register with the platform and receive a time.

• Protocol: because of the limited bandwidth an efficient protocol "protobuf" was selected.

Points of interest:

• Light metering messages

• When the SSLD's are disabled the PSLDs cannot be addressed

Because of these points of interest we use message queueing combined with a retry mechanism of delayed delivery.

The platform and devices use UTC time. The OSLP protocol between platform and devices uses UTC time as well.

Security

The following security measures can be used in a hosted environment:

Cloud security

• DDOS protection

• IPSEC VPN connections

• IP whitelisting

Most cloud environments support these features.

Operating System

• Hardened operating systems (according to Center of Internet Security)

Platform security

• Communication over TLS

• Firewalls between all servers and layers

• Certificates from a recognized Certificate Authority (CA)

• Audit trail on all actions throughout the platform

• Role based authorizations on specific functions of devices

• Access control

• Unique device identification

For every major release there will be a mandated security test initiated by Alliander.

In cooperation with the European Network of Cyber Security (ENCS) state of the art security measures were implemented.

• Security per device

• Security per application

• Security Certificates per Organisation and per device

• All communication is encrypted

Security measures: 1. Firewall in defined zone 2. Operating System Hardening 3. DDOS protection 4. Replay attack prevention 5. Private encryption key per device 6. Certificates from a Certificate Authority 7. Encryption via Elliptic Curve DSA 8. IPSEC VPN for CDMA and GPRS 9. Unique device identification 10. Unique CDMA modem number 11. Role based authorizations on functions and devices

Encryption

An analysis of safety aspects has led to the decision that the safety of the whole system will be realized by proven technology based on asymmetrical coding (also known as public-key encryption).

Authentication of web applications

Two-way SSL will be used between web applications and the Open Smart Grid Platform to verify the identities for both client and server. User organisations are responsible for the administration of the identity of and access to their web applications. The web applications feature a login page. After successful login the user is linked to an organisation. Passwords will be stored with encryption. The organisation ID will be sent in each message to the Open Smart Grid Platform and will be verified by the SSL certificate.

Algorithms

Only public encryption Algorithms will be used. Due to performance limitations (of the devices) and recommendations from The European Network for Cyber Security (ENCS) Elliptic Curve DSA with 256-bit-keys was selected. This improves the security and efficiency over the 1024 bit RSA algorithm. Messages can be smaller and less processor capacity is needed. The key length of Elliptic Curve DSA is similar to the 3072 bit key length of RSA.

Note: Even though the open smart grid platform uses ECDSA to secure the OSLP, other encryptions may be used as well. The RSA Algorithm is still supported if preferred. This is a flexible configuration option.

Private APN

A private APN is used for linking to mobile data communication infrastructures.

Logging

• Every action to and from devices is logged in the audit trail

• Messages from unknown devices will be denied (and logged)

The Open Smart Grid Platform is designed and built for scalability and reliability

• Messages will never get lost, In the worst case scenario, a message will be sent to the dead letter queue.

• Any layer of the platform can be independently scaled up- and down

• Adding servers can be done runtime

• It can run in an active-active setup over multiple servers and data centers. In our cloud hosted setup even over sets of data centers in different countries.

This chapter describes the possibilities of a redundant set up of the Open Smart Grid Platform. The Platform is designed to run in a High Available (or HA) environment, and to prevent data loss due to unexpected failures. Each component of the Platform is designed to be stateless. Components communicate with each other using message queues, which are processed in an asynchronous way.

Active-active

In an active-active setup, multiple instances of each component (eg. Web Services, Core, Protocol Adapter) process the data at the same time. Traffic is equally distributed across the instances. In case of a defect in one instance the traffic is automatically processed by the remaining instance(s). The Open Smart Grid Platform is designed to run in such a set up, and thus preventing down time in case of a failing server. Each component of the Platform can run in an independent, redundant and scalable way.

Database

The Open Smart Grid Platform uses a PostgreSQL database. PostgreSQL supports multiple database servers. For example, a slave and master node, where the slave node continuously replicates the master node. In case the master node fails, the slave mode is triggered and will stop replicating from the master node, execute a recovery and will become the master node.

ActiveMQ

The components of the Platform communicate with each other through a Message Queue. The Open Smart Grid Platform uses Apache Active Message Queue, which makes asynchronous communication possible between components. The components can register to the queues as consumers. In case a consumer (e.g. a server running a component of the platform) is down, the message will still be consumed by the remaining consumer(s). The Message Brokers can be used as a MasterSlave. In case the Master message broker is down, you get immediate fail-over to the slave without loss of messages.

This chapter describes the results of a performance test, to give potential users an indication of the system requirements for the platform.

The Platform was tested with the following AWS setup:

Systems:

• Specifications Component Server: 2 CPU's, 8 GB RAM

• Specifications Database Server: 1 CPU, 2 GB RAM

Setup:

• Front-end: 2x Component Server

• Middle-end: 2x Component Server

• Back-end: 2x Component Server

• ActiveMQ Front-Middle: 1x Component Server

• ActiveMQ Middle-Back: 1x Component Server

• Databases: 1x DB Server

For the test to succeed, two requirements were to be met:

1. Switch 10.000 simulated OSLP devices under 5 minutes.

2. Switch 40.000 simulated OSLP devices under 5 minutes.

The results showed that both tests succeeded.