## Aufbau
### Beschreibung des Aufbaus/der Systemdomänen:
**A - PowerPCB**
Hier wird die physische Sicherheit ("safety") abgebildet. Domäne ist well-defined, reagiert nur auf well-formed Kommandos und bedarf diese in einem definierten Zeitabstand erneut um weiter zu arbeiten. Bleiben Kommandos aus, sind Kommandos mal-formed so wird aktiv jeglicher sicherheitsrelevanter Betrieb eingestellt.
**B - Tablet für HMI**
Besteht aus zwei Softwarekomponenten A1 und A2.
**B1 - Android System**
Hier werden Systemfunktionen (Kernel, Treiber, Netzwerkschicht) bereitgestellt.
**B2 - Userland/GUI App**
Hier wird das Human Machine Interface grafisch dargestellt und via Touch und Drehencoder Eingaben entgegengenommen. Hier werden programmatisch die well-formed Kommandos erzeugt die an (A) geschickt werden.

### Beschreibung der rechtlichen Lage
- Updates müssen möglich sein
- Updates müssen nicht OTA möglich sein.
- ETSI EN 303645 v2.1.0
( https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.00_30/en_303645v020100v.pdf )
- - 5.3: "It is good practice that all software is kept updated and
well maintained. "
- - "All software components in consumer IoT devices should be securely updateable. " - "...should..."
- - Provision 5.3-4 Automatic mechanisms should be used for software updates.
- RFC2119 (https://datatracker.ietf.org/doc/html/rfc2119): "SHOULD This word, or the adjective 'RECOMMENDED', mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."
- "MUST NOT" Aussage des TÜV in Bezug auf Safety toppt "SHOULD" im Bereich Security **-> TÜV Norm ergänzen**

### Vertragliche Lage
- Gegenüber Endkunden: Eine Übernahme der Kosten für Updates wird vom Inverkehrbringer übernommen.
- Updates für B1/B2 werden OTA angeboten.
- Innerhalb der beteiligten Firmen muss vertraglich geregelt werden, dass Kosten weitergegeben werden.
- - Anmerkung Yannik: TGI übernimmt Kosten für Sicherheitsrelavante Themen. Hierfür Rücksprache mit Marko Unger notwendig. Kosten für neue Featurewünsche müssen von Hoyer bzw. Lidl getragen werden.

### Ergebnis
1. Die Firmware in (A) _darf nicht_ OTA updatebar sein da über komprommitierte Firmware die physische Sicherheit gefährdet werden kann.
2. Das Systemimage (A1) _muss_ OTA updatebar sein um auf sicherheitsrelevante Fehler zB. in der Netzwerkschicht/im TCP/IP Stack reagieren zu können.
3. Das HMI (A2) _muss_ OTA updatebar sein um, neben anderen, auf Fehler, die die Kommunikation mit (A) beeinträchtigen, reagieren zu können.
4. Die hier einschlägige ETSI EN 303645 iVm. RFC 2119 schreibt vor, dass Updates machbar sein müssen, nicht, dass sie immer gemacht werden müssen.
5. Die Anforderung des TÜV, physische Sicherheit durch die Nicht-OTA-Updatebarkeit von (A) zu gewährleisten kollidiert mit den Anforderungen von Fa. OBL, _alle_ Komponenten eines IoT Gerätes OTA updatebar zu halten.
6. Updates, die (A) betreffen, können weiterhin durch einen manuellen Eingriff in das Gerät über eine dafür vorgesehene phsische Schnittstelle durchgeführt werden. Eine Sicherheitsevaluation der Firmware für (A) wird regelmässig unternommen. Sollten Fehler bekannt werden, die ein Update von (A) erforderlich machen so werden diese auf Kosten des Inverkehrbringers durch seine Servicestellen für den Endkunden kostenfrei durchgeführt.