Friday, December 29, 2017

New Merging Unit Development Kit

A new Merging Unit Development Kit based on the NovTech IoT Smart Grid Platform with Intel Cyclone V SoC Core is available for your next project.
Utility companies are adapting their infrastructures to support bidirectional energy flow to handle the emergence of DER (Distributed Energy Resources) via microgrids, photovoltaic panels, and local energy storage. As distributed energy generation increases, new intelligence of sensors, measurement and protection equipment will be required to process data at the edge. Also with the increase in variable DER, it is more challenging for substations to deliver sinusoidal and predictable steady-state voltage and current. Utility companies rely on substation metering of secondary voltage (VT) and current transformer (CT) circuits to detect performance issues and to provide vital information in real time to distributed digital protection nodes.

To satisfy this need, SystemCORP and Intel developed an IEC 61850-9-2LE compliant merging unit solution in form of a demonstrator/development platform.

This development kit consists of 6 parts:

  1. NovTech IoT Octopus Smart Grid IoT Platform
  2. SystemCORP VT/CT Interface board
  3. SystemCORP IEC 61850-9-2LE Sample Value software stack (PIS-11) on ARM Cortex A9 core 1
  4. SystemCORP IEC standard 61850 server/client software stack (PIS-10) on ARM Cortex A9 core 2 (optional)
  5. Flexibilis embedded FPGA analogue front-end IP core
  6. Flexibilis Ethernet PRP/HSR FPGA IP core (optional) 

Click HERE for more information.

Saturday, December 9, 2017

IEC TC 57 Publishes Draft for Basic Application Profiles (BAPs)

IEC TC 57 just published Draft for Basic Application Profiles (BAPs):

Development of IEC TR 61850-7-6 (57/1946/DC):
Communication networks and systems for power utility automation
Part 7-6: Guideline for definition of Basic Application Profiles (BAPs) using IEC 61850

Different types are possible:

  1. User profile –defined subset that is valid for a specific user / community of users (e.g. utility)
  2. Domain profile - defined subset for a specific domain and relevant use cases (e.g. asset management)
  3. Basic Application Profile (BAP) – standardized subset defining an atomic application function (e.g. reverse blocking)
  4. Application profile - profile covering a specific application mostly based by aggregating BAPs e.g. busbar protection)
  5. Device profile – profile covering a typical IED functionality e.g. Merging Unit, IEC 61869-9)
  6. Product profile – implemented subset in a specific vendor product

Comments on this draft are due by 2018-01-19.

How many employees will drive an electric vehicle?

A German manager recently said that 500 employees of his company drive by car to the company every workday. He expects that in the future 250 will use electric cars and will charge their cars within the first hour after they arrived. The company would need 10 times more power than today!
Ok! Hm!?
What do you think about these assumptions? 250 EVs charging in the first hour!?
As an engineer I am wondering that experts come up with such examples. First of all, I do not expect that 50 per cent of the car owners will buy an electric car in the next years. Even if they would do, why do 250 car drivers want to charge at the companies car park in the morning when they arrive?
He concludes that "we engineers have not yet thought through to the end".
I guess a lot of engineers have thought through to the end - but not many engineers or politicians are listening!

Click HERE for the report "Netzstabilität braucht Digitalisierung und Automatisierung" in the vdi nachrichten (German).

These discussions remind me of the situation in the early 80s when we had the discussion on CSMA/CD (Ethernet, IEEE 802.3) versus Token Passing (IEEE 802.4). Under the assumption that we have a shower of messages to be sent by all attached devices at the same time, we found that Ethernet could not efficiently manage the communication due to many collisions. Token Passing was understood to manage such a situation very well. Ok.
Another assumption, high load from one device only, could easily be managed by CSMA/CD - but Token Passing would end up in very low throughput ... many other assumptions could be made.
So, what is the realistic assumption for communication? Nobody knows - it all depends.
Finally Switched Ethernet (a major new development) solved the collision problem ... and Token Passing more or less became obsolete in the automation world.

In the energy domain we need first to find the future new mix of power generation and how to store, transmit, distribute, and use the power - then we can think about automation and communication. The most crucial issue may be: Who is paying for all the changes?

By the way: We (many engineers) know how to communicate: IEC 61850 is one of the most crucial solution ... and how (not yet what) to automate.