Der Controller ist der Ort, an dem ein Ladegerät aufhört, verkabelt zu sein, und zu einem Produkt wird. Es betreibt die Ladezustandsmaschine, liest den Zähler aus, überwacht die Schutzschnittstellen, steuert das Schütz, verwaltet die Konnektivität und spricht das Protokoll.
Diese Kombination aus Echtzeit-Sicherheitsarbeit und vernetzter Anwendungsarbeit auf einem Gerät ist die zentrale Designspannung, und die Art und Weise, wie sie gelöst wird, prägt alles andere.
Was der Controller tun muss
- Generieren und überwachen Sie den Steuerpiloten und setzen Sie seine Zustandsmaschine innerhalb der angegebenen Zeitspanne durch.
- Lesen Sie die Nähe dort ab, wo ein abnehmbares Kabel unterstützt wird.
- Fahren Sie das Schütz an und prüfen Sie, ob es reagiert.
- Lesen Sie den Zähler ab und melden Sie die Energie genau.
- Überwachen Sie Schutzschnittstellen und reagieren Sie, ohne auf etwas Langsameres warten zu müssen.
- Verwalten Sie die Konnektivität aller installierten Träger.
- Führen Sie den Protokoll-Client aus, einschließlich Persistenz und Warteschlangen.
- Wenden Sie Firmware-Updates sicher an, mit einem Rückpfad, falls ein Update fehlschlägt.
Sicherheitskritische Arbeit und Best-Effort-Arbeit passen nicht gut zusammen
Piloten-Timing und Schutzreaktion haben strenge Fristen. Netzwerkverkehr, Protokollverarbeitung und Firmware-Downloads gelten nicht. Wenn beide auf einem Kern mit einem gemeinsamen Scheduler ausgeführt werden, kann der zweite den ersten unter Last verzögern.
Designs lösen dieses Problem, indem sie die Domänen entweder auf separate Prozessoren oder durch eine strikte Prioritätstrennung aufteilen, wobei der Sicherheitspfad nicht durch Anwendungsarbeit blockiert werden kann. Welcher Ansatz verwendet wird, ist eine der entscheidenden Architekturentscheidungen.
Der Aktualisierungspfad ist eine Designbeschränkung
Ein Ladegerät, das durch ein fehlgeschlagenes Update beschädigt werden kann, ist ein Ladegerät, für dessen Wiederherstellung ein Besuch vor Ort erforderlich ist. Um dies zu verhindern, ist ein Speicher erforderlich, der ein funktionierendes Image speichern kann, während ein neues geschrieben wird, und ein Bootloader, der entscheiden kann, welches ausgeführt werden soll.
Diese Entscheidung schränkt die Speicher- und Flash-Größe ein und ist schwierig nachzurüsten, da es im Wesentlichen um das Speicherlayout geht.
Identität und Geheimnisse
Der Controller verfügt über Anmeldeinformationen, die ihn gegenüber einem Backend authentifizieren. Wo sie gespeichert werden, ob sie extrahiert werden können und wie sie bei der Herstellung bereitgestellt werden, sind Sicherheitsentscheidungen mit Auswirkungen auf das Design.
Ein Design, bei dem jede Einheit einen gemeinsamen Ausweis hat, ist einfach zu erstellen und führt zu einem einzigen Kompromiss, der sich auf die Flotte auswirkt. Anmeldeinformationen pro Einheit erfordern einen Bereitstellungsprozess am Ende der Leitung, weshalb Programmierung und Sicherheitsdesign dasselbe Thema sind.
Diagnostizierbarkeit ist eine Architektureigenschaft
Wenn sich eine Einheit vor Ort schlecht verhält, hängt das, was aus der Ferne festgestellt werden kann, davon ab, was der Controller aufzeichnet und offenlegt. Ein Design, das nur Fehler protokolliert, kann keine Fragen zu Sequenzen beantworten, und in Sequenzen treten zeitweilige Fehler auf.
Die Entscheidung darüber, was aufgezeichnet werden soll, wie viel gespeichert werden soll und wie es abgerufen werden soll, ist zur Entwurfszeit kostengünstig und kann nicht zu einer bereitgestellten Flotte hinzugefügt werden.
Thermische Realität
Der Controller befindet sich in einem versiegelten Gehäuse neben einer Schützspule, die kontinuierlich Verluste abgibt. Die Leiter führen stundenlang den Nennstrom und sind in vielen Fällen direkter Sonneneinstrahlung ausgesetzt. Die Komponentenwerte müssen die Innentemperatur und nicht die Außentemperatur widerspiegeln.
Im Freien validierte Designs verhalten sich bei aufgesetztem Deckel anders, weshalb die thermische Validierung im tatsächlichen Gehäuse und nicht auf einer Werkbank erfolgt.
Kaufen oder bauen
Ein Hersteller, der sich mit Gehäusen, Strompfaden und Kabeln auskennt, kann vernünftigerweise zu dem Schluss kommen, dass der Controller das Teil ist, das gekauft und nicht gebaut werden muss, da für ihn eine Protokollwartungspflicht besteht, die niemals endet.
Das ist eher eine legitime Architekturentscheidung als ein Eingeständnis. Wichtig ist, dass die Grenze definiert ist: was der Controller besitzt, was das umgebende Produkt besitzt und wer verantwortlich ist, wenn ein Fehler diese Grenze überschreitet.