Dit hoofdstuk geeft een overzicht van de huidige stand van zaken met betrekking tot dit dossier. Aangezien nog niet alle keuzes definitief zijn gemaakt, kan ook deze samenvatting in de loop van de tijd nog wijzigen.
Dit document dient om invulling te geven aan artikel 13, lid 6 van EU-verordening (EU) 2016/631 van 14 april 2016, naar de afkorting van de Engelse titel meestal aangeduid als "RfG". Dit document benadert de verordeningen vanuit interface-eisen die kunnen worden gesteld aan elektriciteitsproductie-eenheden (zoals in RfG) en vraag-gestuurde -load- devices (zoals in DCC). Hierbij wordt vooral gebaseerd op het beginsel van optimalisering wat betreft de hoogste totale efficiëntie en laagste totale kosten voor alle betrokken partijen. Naast RfG type A (800W - 1MW), wordt conform RfG ook Type B (1MW - 50MW) gespecificeerd.
Een complicerende factor in de laagst maatschappelijke kosten is, dat momenteel nog niet volledig bepaald is welke elektriciteitproductie-eenheden er later aangestuurd zullen worden. Dit betekent een afweging tussen kosten voor het "overbodig" eisen van een interface versus de hoge kosten voor narusting door ongedefinieerde interfaces in het veld (zie figuur). T.b.v. mitigatie van dit dilemma wordt er daarom gestuurd op een standaard software-oplossing/software-stack die in huidige firmware van hardwareleveranciers (zoals PV converters) kan worden geïntegreerd om per éénheid de laagste kosten te garanderen. Aangezien integratie niet altijd het geval kan zijn, is het ontwerp van de interface dermate klein gehouden dat het in zeer goedkope extra hardware kan worden omgezet. Hiermee kan er een gateway als commercieel product van niet meer dan € 25,00 (ofwel ca. 1,5 % van de aller kleinste installaties) ontstaan indien deze extra hardware überhaupt noodzakelijk is. Uitgangspunt is dat het achteraf narusten van interfaces of het plaatsen van extra gateways op bestaande hardware proportioneel veel kost t.o.v. directe levering.
Het is denkbaar dat er verschillende eisen zullen gelden, afhankelijk van de relevantie van de productie-eenheid. Hiervoor definiëren we verschillende "klassen" van de interfaces. Klasse 1 is de meest eenvoudige, een hoger nummer klasse is meer compleet en zal uiteindelijk kunnen groeien naar een volledig uitgewerkte internationaal gestandaardiseerde interface. Aangezien het niet ondenkbaar is dat de grenzen van de vermogens (tussen RfG Type A en RfG Type B) in de toekomst kunnen wijzigen, zijn de "klassen" los gedefinieerd van de RfG Type A en Type B en meer verbonden met de relevantie in het net.
Naast het beginsel van optimalisering voor laagste kosten voor alle partijen, wordt ook gestreefd naar het zoveel mogelijk toepassen van eenvoud, IT standaarden, OT standaarden, privacy-bescherming en toepassen van security-by-design. Hierbij staat security niet alleen voor de IT componenten, maar ook de invloed op het elektriciteitsnet. Het autonome gedrag van de elektriciteitsproductie-eenheden, zoals in overige delen van de RfG gespecificeerd, dragen bij aan het secure design van het geheel op lokaal niveau.
Als uitkomst, wordt er aan fabrikanten of installateurs van elektriciteitproductie-eenheden gevraagd een IT interface aan te bieden die met een IP verbinding over bestaande netwerkverbindingen (bijvoorbeeld WIFI netwerken) verbonden kunnen worden. Voor meer significante elektriciteitsproductie-eenheden, die mogelijk de netstabiliteit kunnen beïnvloeden, wordt er minimaal ook een fysieke Ethernet aansluiting vereist om hiermee de interface met een specifiek IP netwerk van de systeembeheerders te kunnen verbinden. Met de IP verbinding wordt de elektriciteitproductie-eenheid geregisteerd bij een centrale-aanmeldadres (of indien niet beschikbaar tijdelijk direct bij één van de Netbeheerders). In combinatie met een web-based registratie kan deze centrale-aanmeldpartij de juiste Netbeheerder vinden en doorverwijzen. Hiermee worden de verbindinggegevens van de relevante netbeheerder en de veiligheidscertificaten uitgedeeld. Bij de communicatie tussen de elektriciteitproductie-eenheden en de overige systemen, wordt nooit direct interpreteerbare data uitgewisseld waarmee de identiteit van de producment of de locatie in het net kan worden achterhaald. Deze informatie wordt centraal afgeschermd pas aan elkaar gerelateerd (eenheiddata - positie in het net).
Voor de operationele uitwisseling van data is op dit moment is de roadmap van IEC 61850 leidend, met XMPP toepassing (61850 deel 8-2) zoals bedoeld voor DER (distributed energy resources). Tevens wordt naar voorbeeld van de Duitse Steuerbox het gebruik van schedules uitgewerkt in concrete BAP's die door leveranciers kunnen worden toegepast. Een voorbeeld BAP is bijgevoegd en dient ter illustratie. Een BAP voor werkelijke implementatie wordt uitgewerkt in detailspecificaties.
Een grote uitdaging lag in het aanmelden en afmelden van devices in combinatie met het security-concept in te richten. Hiervoor is het gehele proces uitgetekend, inclusief één mogelijke centrale opbouw van systemen. Dit wil niet zeggen dat de systemen waarmee de productie-eenheden straks gaan communiceren, daadwerkelijk centraal zijn opgesteld. Op basis van deze uitgetekende processen en de bijbehorende sequence diagrammen is de algehele informatiebehoefte duidelijk. Na het uitwerken van operationele uitwisseling (zie alinea hierboven) wordt ook bij het aanmelden de concrete datauitwisseling in een detailspecificatie verder uitgewerkt.
Er is continue getoetst of de keuzes die gemaakt zijn, eventueel voor leveranciers maakbaar, implementeerbaar en in eenvoudige hardware omzetbaar is. Dit lijkt momenteel over het algemeel wél het geval.
Na het specificeren van de interface zal daarna ook andere taken moeten worden uitgevoerd. Deze worden in de zogenaamde "issue lijst" bijgehouden. Het betekent dat alle issue's die hier staan ook handvatten bieden voor vervolgvraagstukken zoals detailspecificatie, bouwen, testen, conformiteit, etc.