Het businesskader wordt beschreven a.d.v. een SGAM plane waarbij de verantwoordelijkheden van de DSO en de overige partijen is gevisualiseerd (zie Figuur 5). In het rood zijn de verantwoordelijkheden aangegeven van de DSO en in het groen van de “Overige partijen”. Op dit moment is het nog irrelevant om te definiëren wie deze “Overige partijen” precies zijn; bijvoorbeeld leveranciers van hardware, aggregator, etc. De TSO is hier vanwege de tekenwijze en overzichtelijkheid weggelaten, maar de uitkomsten zullen voor TSO en DSO hetzelfde zijn m.b.t. de interfacespecificatie.
Ook de informatie-en-opdrachten-infrastructuur (witte vlek in Figuur 5) waarmee de interfaces straks gaan verbinden is op dit moment voor een groot gedeelte irrelevant. Vragen of deze systemen centraal of decentraal zijn en of deze de TSO/DSO of een marktpartij toebehoren is voor de interface (nog) irrelevant. Wel zullen een aantal eigenschappen van deze toekomstige centrale of decentrale informatie-en-opdrachten-infrastructuur nu al duidelijk moeten worden om te kunnen interacteren met de interfaces. Er moet bijvoorbeeld duidelijkheid zijn over bepalingen zoals encryptie, tijdsynchronisatie, etc. Dit wordt later in dit document wel beschreven.
Figuur 5
Zoals in het bovenstaande figuur is weergegeven zijn er 4 categorieën elektriciteitproductie-eenheden te onderscheiden met elk hun vermogensgrenzen, die in de toekomst nog kunnen wijzigen. Het is van belang dat het ontwerp hiermee rekening houdt. Concreet: een Type A zal (met name voor leveranciers van hardware) gemakkelijk geüpgraded moeten kunnen worden tot een Type B. De uitdaging bij RfG Type A (800W - 1MW) zit voornamelijk in de aantallen devices, de uitdaging bij Type B (1MW - 50MW) zit voornamelijk in de mogelijke impact in de stabiliteit het Elektriciteitsnet (zie Figuur 1). RfG Type C en Type D zijn van aantallen beperkt waarvoor maatwerk-aansluitingen zullen worden uitgevoerd. Hoewel de technologie van A en B hiervoor kan worden gebruikt, is het expliciet specificeren van Type C en D buiten scope. Daarnaast zal er ook voor DCC (sturen van belastingen volgens verordening "DCC") een interface beschikbaar moeten komen. Eenduidigheid tussen de RfG en de DCC interface wordt wel nagestreefd maar is niet de primaire doelstelling van de RfG interfacespecificatie.
Binnen Type A bestaan er varianten waarbij de elektrische aansluiting op een middenspanningsruimte plaatsvindt (ongeveer >300 of >400kVA) en dus schakelbaar. Daarnaast zijn er varianten met een lager vermogen die niet schakelbaar zijn door lagere positionering in het elektriciteitsnet (gecombineerde aansluitingen). RfT Type A met een lager vermogen zullen vanuit kostenperspectief zoveel mogelijk gebruik moeten maken van bestaande communicatiestructuren. Het is nog niet gedefiniëerd welke triggers ervoor gaan zorgen dat deze verbinding daadwerkelijk wordt gerealiseerd. Bijvoorbeeld: wat drijft een prosument ertoe zijn/haar PV-converter met het internet te verbinden? Als er een te grote populatie ontstaat die niet verbonden zijn, zullen er extra maatregelen moeten worden genomen met extra maatschappelijke kosten tot gevolg. Het af-en-toe niet beschikbaar zijn van communicatie met de eenheden is beperkt kritisch, vanwege het autonome gedrag van deze elektriciteitproductie-eenheden zoals voorgeschreven in de overige delen van de RfG. Het toevoegen van schedules in de eenheden naar Duits voorbeeld kunnen het autonome gedrag en daardoor robuustheid versterken. Hiermee wordt de beschikbaarheidseis van 99,90% bij de requirements op een andere manier gerealiseerd, namelijk iets onafhankelijker van communicatieverbindingen.
Praktisch geldt dat met de huidige vermogensgrenzen, Type B al vaak vanuit een DSO onderstation of middenspannigsruimte elektrisch is aangesloten en hiermee dus schakelbaar (al dan niet op afstand). Ze zijn daarmee nog niet regelbaar zoals wèl binnen de RfG voor type B is vereist. Het terugregelen van een productie-eenheid naar bijvoorbeeld 50% van Pmax is ook klantvriendelijker dan de complete aansluiting spanningsloos te maken. Daarnaast kan een RfG type B niet automatisch voldoen aan het ontsluiten van Real-time data zoals vereist in RfG artikel 14.5d. Voor Type B geldt dus ook de behoefte aan een specificatie voor aan de vereisten vanuit de RfG te kunnen voldoen. Verder gelden dezelfde overwegingen als in RfG type A.