Software-Compliance Guide 2021 extern (gültig ab 01.07.2021) Beitrag zur Sicherstellung von technischer Compliance in der SW-Entwicklung - Daimler
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Software-Compliance Guide 2021 extern (gültig ab 01.07.2021)
Beitrag zur Sicherstellung von technischer Compliance in der SW-Entwicklung
Dieser Software-Compliance Guide wurde auf der Grundlage von Gesetzestexten und internen Richtlinien erstellt, ohne deren Inhalt
vollumfänglich abzubilden. Er dient als Orientierungshilfe für die Entwicklungsarbeit von Software (Spezifikation, Konzeption,
Coding) und basiert auf Daimlers Grundverständnis von technischer Compliance. Entsprechend ersetzt der Guide nicht die
bereits etablierten Prozesse und Anforderungen innerhalb der einzelnen Compliance-Kategorien.
Die im SW-Compliance Guide formulierten Anforderungen gehen teilweise über den vereinbarten Lieferumfang hinaus, so dass das
funktionale Gesamtsystem betrachtet werden muss. Daher müssen externe Auftragnehmer1 sich bei der Festlegung der
Systemgrenzen und somit des zu betrachtenden Systemumfangs mit dem entsprechenden Auftraggeber abstimmen.
Bei Fragen können Sie sich an sw-compliance-guide@daimler.com wenden.
1. In diesem Guide wird allein aus Gründen der sprachlichen Vereinfachung für natürliche Personen lediglich die männliche Form verwendet. Inhaltlich sind stets
Personen aller geschlechtlichen Identitäten gemeint. Der Begriff "Mitarbeiter" umfasst auch die Führungskräfte aller Ebenen und Mitglieder geschäftsführender Organe.
Kapitel 01.00 | Software-Compliance Guide 2021 extern| gültig ab 01.07.2021
Compliance ist uns wichtig.
„Compliance und Integrität sind für uns bei
Daimler fester Bestandteil des Geschäftslebens.
Wir erwarten eine solche Haltung von allen
Beschäftigten, aber auch von unseren Partnern.“
Renata Jungo Brüngger,
Mitglied des Vorstands der Daimler AG und
Mercedes-Benz AG, verantwortlich für Integrität
und Recht
Sicherstellung von technischer Compliance in der Software Entwicklung 2
Kapitel 01.01 | Software-Compliance Guide 2021 extern| gültig ab 01.07.2021
Compliance ist uns wichtig.
Technical Compliance technical Compliance Management System (tCMS)
Einhaltung technisch-regulatorischer Anforderungen,
Standards und Gesetze unter Berücksichtigung der Das technical Compliance Management System (tCMS)
grundsätzlichen Zielsetzung der Gesetze und Regularien
Einhaltung von internen Entwicklungsvorgaben und • stellt rechtliche und regulatorische Konformität
-prozessen innerhalb des Produktentstehungsprozesses sicher
• gibt unseren Beschäftigten Sicherheit und Orientierung
Bewusstsein für Ziele und Hintergründe von Gesetzen schaffen durch Werte, Prinzipien, Strukturen und Prozesse.
Sicherstellung von technischer Compliance in der Software Entwicklung 3
Kapitel 01.02 | Software-Compliance Guide 2021 extern| gültig ab 01.07.2021
Der Software-Compliance Guide definiert zentrale Begrifflichkeiten und
Prinzipien
Ziele des Guide
Schaffung von Transparenz über zentrale Begrifflichkeiten
bezüglich technischer Compliance
Verankerung von grundsätzlichen Prinzipien zu technischer
Compliance in Daimlers Unternehmenskultur
Vorstellung von Maßnahmen, die dazu beitragen, technische
Compliance sicherzustellen
Sicherstellung von technischer Compliance in der Software Entwicklung 4
Kapitel 01.03 | Software Compliance Guide 2021 extern| gültig ab 01.07.2021
Der Software-Compliance Guide ist weltweit für alle Entwicklungsbereiche
bei MBC (inkl. CASE & QM/RZ), MBG, VAN und AMG gültig
Scope des Guide
•Der Software Compliance Guide ist für alle Softwareentwicklungsprozesse zu beachten und gilt dabei:
Für alle Mitarbeiter der
Entwicklungsbereiche sowie
Entwicklungs-Dienstleister und
Lieferanten der Mercedes-Benz
AG, Mercedes-AMG GmbH
sowie Mercedes-Benz G GmbH
Weltweit
Ab dem Zeitpunkt der
Veröffentlichung
Sicherstellung von technischer Compliance in der Software Entwicklung 5Kapitel 02.01 | Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Regulatorische Vorgaben für die Software-Entwicklung lassen sich in fünf
Kategorien unterteilen
Ziele Kategorie Sub-Kategorien
Sicherstellung der Vertraulichkeit,
Integrität, Verfügbarkeit, sowie des Daten- & Software-
Datensicherheit und Abgrenzung
rechtmäßigen und verantwortungs- sicherheit & -verfügbarkeit
Datenschutz
Telekommunikationsgesetz*
vollen Umgangs mit Daten/
Software TK-Recht**
Sicherstellung, dass nur sichere Produkt-
Produkte in den Verkehr gebracht Aktive Sicherheit Passive Sicherheit Gefahrenschutz
werden sicherheit
Sicherstellung, dass regulatorische Emissionen (gesetzl.
Verbrauch, CO2 &
und interne Anforderungen an den Umwelt OBD*
Reichweite
Geräusch limitierte Schad-
Umweltschutz erfüllt werden stoffe) & EMV*
Sicherstellung der
Verwertungsrechte und Schutz- & Ver- Technische Schutz- Softwarespezifische Nichttechnische Geschäfts-
rechtmäßigen Nutzung von rechte (Patente) Urheberrechte Schutzrechte geheimnisse
Software
wertungsrechte
Sicherstellung der Erfüllung von Produkt- Kongruenz beworbener & Konsistenz der
Kundenerwartungen für Funktionen Konsistente Informationen*
& Eigenschaften konformität tatsächlicher Funktionen Produktdokumentation
* Siehe Begriffsdefinition im Backup; ** TK-Recht = Telekommunikationsrecht Sicherstellung von technischer Compliance in der Software Entwicklung 6Kapitel 02.02| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Grundsätzliche Prinzipien für technische Compliance
Grundsätzliche Prinzipien
Sicherstellung der Vertraulichkeit,
•Compliance
Integrität, und
Verfügbarkeit, sowie Daten- sind
des Integrität & Software-
feste Bestandteile der Unternehmenskultur der Mercedes-Benz AG, Mercedes-AMG GmbH
Datensicherheit und Abgrenzung
sowie
rechtmäßigen undMercedes-Benz
verantwortungs- sicherheit
G GmbH und & unseres Geschäftsalltags.
-verfügbarkeit
Datenschutz
Telekommunikationsgesetz*
vollen Umgangs mit Daten/
Software TK-Recht**
•Die Mercedes-Benz AG, Mercedes-AMG GmbH sowie Mercedes-Benz G GmbH entwickeln Software nach Grundsätzen, dass…
•technisch-regulatorische Anforderungen, Standards, interne und externe Normen, Software
Qualitätsmanagement-Handbuch
Sicherstellung, dass nur sichere Produkt- (QMH) Vorgaben und Gesetze stets eingehalten,
Produkte in den•Risiken
Verkehr gebracht
für Leib Aktive
und Leben sowie Sachen SicherheitGegenstände)Passive
(körperliche Sicherheitund angemessenen
mit möglichen Gefahrenschutz
Maßnahmen
werden sicherheit
minimiert,
•die Umwelt geschützt,
•sowie Ressourcen bestmöglich geschont werden.
Sicherstellung, dass regulatorische Emissionen (gesetzl.
Verbrauch, CO2 &
und interne Anforderungen an den
•Die Software, Umwelt OBD* Geräusch limitierte
stetsSchad-
Umweltschutz erfüllt werden die die Mercedes-Benz AG, Mercedes-AMG GmbH sowie Mercedes-Benz G GmbH
Reichweite entwickeln, wird unter
stoffe) & EMV*
Berücksichtigung von Compliance und Integrität auf vorhersehbares Kundenverhalten ausgelegt.
•Notwendige Kommentare im Code von Software werden verständlich und sachbezogen formuliert; zu speichernde Daten
Sicherstellung der
sind eindeutig
Verwertungsrechte und Schutz- & Ver-
definiert. Technische Schutz- Softwarespezifische Nichttechnische Geschäfts-
rechtmäßigen Nutzung von rechte (Patente) Urheberrechte Schutzrechte geheimnisse
•Softwarefunktionen* wertungsrechte
Software berücksichtigen den Umfang der Fahrzeugausstattung und werden darauf ggf. bedarfsgerecht
angepasst.
Sicherstellung der Erfüllung von Produkt- Kongruenz beworbener & Konsistenz der
Kundenerwartungen für Funktionen Konsistente Informationen
& Eigenschaften konformität tatsächlicher Funktionen Produktdokumentation
* Siehe Begriffsdefinition im Backup; Sicherstellung von technischer Compliance in der Software Entwicklung 7Kapitel 03.01 | Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Daten- & Softwaresicherheit
Grundsätzliche Prinzipien
Sicherstellung der Vertraulichkeit,
Integrität, Verfügbarkeit, sowie des Daten- & Software-
Datensicherheit und Abgrenzung
rechtmäßigen und verantwortungs- sicherheit & -verfügbarkeit
Datenschutz
Telekommunikationsgesetz*
vollen Umgangs mit Daten/
Software TK-Recht**
Sicherstellung, dass nur sichere Produkt-
Produkte in den Verkehr gebracht Aktive Sicherheit Passive Sicherheit Gefahrenschutz
werden sicherheit
Sicherstellung, dass regulatorische Emissionen (gesetzl.
Verbrauch, CO2 &
und interne Anforderungen an den Umwelt OBD*
Reichweite
Geräusch limitierte Schad-
Umweltschutz erfüllt werden stoffe) & EMV*
Sicherstellung der
Verwertungsrechte und Schutz- & Ver- Technische Schutz- Softwarespezifische Nichttechnische Geschäfts-
rechtmäßigen Nutzung von rechte (Patente) Urheberrechte Schutzrechte geheimnisse
Software
wertungsrechte
Sicherstellung der Erfüllung von Produkt- Kongruenz beworbener & Konsistenz der
Kundenerwartungen für Funktionen Konsistente Informationen
& Eigenschaften konformität tatsächlicher Funktionen Produktdokumentation
* Siehe Begriffsdefinition im Backup; ** TK-Recht = Telekommunikationsrecht Sicherstellung von technischer Compliance in der Software Entwicklung 8Kapitel 03.02| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für Datensicherheit und -verfügbarkeit
(onboard wie offboard)
•Softwarefunktionen sind so zu gestalten, dass die Speicherung und Übertragung von Daten angemessen geschützt wird
und die Daten somit nicht zugänglich für unbefugte Dritte sind. Dies muss insbesondere durch den Einsatz von geeigneten
kryptographischen Verfahren sichergestellt werden (z.B. TLS-Verschlüsselung als Standard für systemübergreifende
Kommunikation).
Vertraulichkeit
•Softwarefunktionen sind so zu gestalten, dass Zugriffskontrollen geregelt sind, um unberechtigte Zugriffe zu vermeiden.
Sicherzustellen ist daher insbesondere:
–Die Gewährung von Datenzugriffsrechten nach dem „need to know“ Prinzip
–Die regelkonforme Authentifizierung und Autorisierung von Benutzern (z.B. Zwei-Faktor Authentifizierung)
•Softwarefunktionen sind so zu gestalten, dass die Authentizität von Sender und Empfänger sichergestellt ist (z.B. durch
Authentizität
Verwendung von digitalen Signaturen).
•Softwarefunktionen sind so zu gestalten, dass ungewollte bzw. böswillige Änderungen identifiziert werden können (z.B.
Fälschungssicherheit
mithilfe von digitalen Signaturen oder kryptographisch gesicherten Hash-Algorithmen).
•Softwarefunktionen sind so zu gestalten, dass Systemausfälle bestmöglich vermieden werden (z.B. durch regelmäßige
Durchführung von Updates und Patches).
Ausfallsicherheit
•Softwarefunktionen sind so zu gestalten, dass für den Fall eines Systemausfalls abhängig von ihrer Kritikalität redundante
Backupsysteme vorgesehen sind.
•Softwarefunktionen sind so zu gestalten, dass ungewollte Datenverluste bestmöglich vermieden werden (z.B. durch
Datensicherung
Erstellung und regelmäßige Überprüfung von Backups oder Verwaltung durch Repository-Systeme).
Sicherstellung von technischer Compliance in der Software Entwicklung 9Kapitel 03.03| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für Datenschutz - (1/3)
• Jede Verarbeitung* personenbezogener Daten* benötigt zwingend eine Rechtsgrundlage.
Als Rechtgrundlage kommen insbesondere in Betracht:
Vertrag mit dem Betroffenen
Rechtmäßigkeit Einwilligung des Betroffenen
Gesetzliche Pflicht zur Verarbeitung
„Berechtigtes Interesse“ an der Verarbeitung (dies ist sorgfältig bzw. restriktiv zu prüfen)
• Softwarefunktionen sind so zu gestalten, dass personenbezogene Daten stets für festgelegte, eindeutige und legitime
Zwecke verarbeitet werden, für die es eine Rechtsgrundlage gibt (siehe Abschnitt Rechtmäßigkeit).
Zweckbindung
• Für eine Änderung des Zwecks der Verarbeitung von Daten bedarf es auch einer Rechtsgrundlage. Sie ist nur in engen
Grenzen zulässig und nur sofern der neue Zweck nicht unvereinbar mit dem ursprünglichen Zweck ist.
• Softwarefunktionen sind insbesondere so zu gestalten, dass
der Umfang der Verarbeitung (wie Erhebung, Speicherung, Übertragung,…)
die Aufbewahrungsdauer
Zugänglichkeit / Speicherort (an möglichst wenigen Stellen)
von personenbezogenen Daten angemessen, relevant und tatsächlich erforderlich für den jeweiligen Zweck sind.
Datenminimierung • Nicht (mehr) benötigte personenbezogene Daten dürfen nicht verarbeitet werden und sind zu löschen.
• Personenbezogene Daten sind frühestmöglich zu anonymisieren, sofern ein Personenbezug nicht erforderlich ist. Dies gilt
insbesondere bei der Datenübertragung aus dem Fahrzeug.
• Maßnahmen zur Datenminimierung sind z.B. „Unschärfe“ (bzgl. km-Stand, GPS-Position, Uhrzeit); Klassenbildung statt
exakter Werte etc.(vergleiche dazu auch Verfahrensanweisung V9990040).
Quellen/Grundlagen: Relevante Gesetze und Verordnungen (insbs. EU-DSGVO) sowie interne Richtlinien: Daimler Datenschutzrichtlinie (A17), Globale Daten- und Informationsrichtlinie
(A22), Leitfaden zur Zulässigkeit der Nutzung personenbezogener Daten für IT-Entwicklungs- und Testzwecke sowie spezifische Verfahrensanweisungen (Bsp. RD: V9990040
„Datenspeicherung im Fahrzeug“).
* Siehe Begriffsdefinition im Backup Sicherstellung von technischer Compliance in der Software Entwicklung 10Kapitel 03.03| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für Datenschutz - (2/3)
• Die Lösch- und Speicherkonzepte für personenbezogene Daten orientieren sich an der Zweckbindung und dürfen nicht
durch den Informationsaustausch zwischen Komponenten oder die Speicherung der Daten durch andere Komponenten
gefährdet sein.
Speicherung / • Die Anforderungen an Lösch- und Speicherkonzepte orientieren sich an der Schutzwürdigkeit der Daten. Bei
Löschung besonderen Daten, die z.B. eine umfassende Fahrerprofilbildung ermöglichen würden, oder bei Gesundheitsdaten, ist zu
prüfen, ob diese unbedingt gespeichert werden müssen (u.U. kann es ausreichen, die Daten nur flüchtig, d.h. nicht über
einen Zündungswechsel hinaus, zu nutzen). Wenn diese gespeichert werden müssen, sind sie verschlüsselt im Fahrzeug
zu speichern und ggf. ist die Zugriffsmöglichkeit zu begrenzen.
• Bei verwendeten Datenquellen ist zu gewährleisten, dass personenbezogene Daten zum Zeitpunkt der Erhebung richtig,
Datenaktualität
vollständig und aktuell sind.
• Datenschutzanforderungen sind frühzeitig bereits bei Konzeption bzw. Spezifikation von Softwarefunktionen zu
berücksichtigen.
• Datenschutzanforderungen sind durch technische und organisatorische Maßnahmen zu implementieren (z.B.
Transparenz durch Information über Datenverarbeitung, Verschlüsselung, Wahlmöglichkeiten für Nutzer, Daten- und
Privacy by Design / Zugriffstrennung durch Nutzerprofile, automatische Löschung nicht mehr benötigter Daten etc. ...).
Privacy by Default
• Softwarefunktionen sind so zu gestalten, dass Nutzer die Erhebung ihrer personenbezogenen Daten steuern können
(z.B. widerrufen, einschränken, pausieren, permanent stoppen, löschen, etc.). Diese Steuerung muss benutzerfreundlich
zugänglich sein.
• Grundeinstellung muss in der Regel die datenschutzfreundlichste Einstellung sein.
Quellen/Grundlagen: Relevante Gesetze und Verordnungen (insbs. EU-DSGVO) sowie interne Richtlinien: Daimler Datenschutzrichtlinie (A17), Globale Daten- und Informationsrichtlinie
(A22), Leitfaden zur Zulässigkeit der Nutzung personenbezogener Daten für IT-Entwicklungs- und Testzwecke sowie spezifische Verfahrensanweisungen (Bsp. RD: V9990040
„Datenspeicherung im Fahrzeug“).
Sicherstellung von technischer Compliance in der Software Entwicklung 11Kapitel 03.03| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für Datenschutz - (3/3)
• Softwarefunktionen sind so zu gestalten, dass
Betroffene / Nutzer Informationen über die Datenverarbeitung erhalten; in transparenter Weise und vor bzw.
gegebenenfalls auch während der Verarbeitung (siehe Beispiele).
Die Information stets vor Abfrage der Einwilligung bzw. Zustimmung zu Datenschutzhinweisen erfolgt („informierte
Einwilligung/ informiertes Handeln“).
Beispiele: Hinweise in Anzeige / Menü, Bedienungsanleitung, Datenschutz-Hinweisen / Nutzungsbedingungen etc.; Anzeige von Icons im
Display, wie z.B. ein „Kamera-Icon“, wenn die Kamera Bild-/Videoaufnahmen speichert bzw. überträgt, oder „Standort-Dienst-Aktiv-Icon“ etc.
Der Auskunftsanspruch der Betroffenen / Nutzer bezüglich der Verarbeitung ihrer Daten erfüllt werden kann.
(Wenn die Daten erhoben werden, z.B. in Mercedes me connect, besteht ein Anspruch des Betroffenen, diese Daten zu erhalten)
Information /
Transparenz / • Bei besonders datenschutzrelevanten Systemen (z.B. Innenraumkameras, Sprachbedienung) ist eine entsprechende
Rechenschaftspflicht Dokumentation der Systemfunktionalität bzgl. Erklärbarkeit gegenüber dem Kunden zu erstellen und mit dem
Konzerndatenschutz abzustimmen. Diese ist bei Änderungen ggf. zu aktualisieren.
• Die Dokumentation über die in einem Steuergerät nicht-flüchtig gespeicherten und/oder übertragenen Datenpunkte
ist für jede Softwareversion zu gewährleisten. Hierzu gehört neben der Benennung eine aussagekräftige Beschreibung
jedes Datenpunktes.
• Die Einhaltung der Datenschutzanforderungen muss nachgewiesen werden können. Je nach Fall und Erforderlichkeit muss
daher beispielsweise dokumentiert werden:
Durchführung und Dokumentation einer Datenschutzfolgeabschätzung
Dokumentation im Verfahrensverzeichnis
Dokumentation sonstiger datenschutzrelevanter Aspekte (fallabhängig)
Quellen/Grundlagen: Relevante Gesetze und Verordnungen (insbs. EU-DSGVO) sowie interne Richtlinien: Daimler Datenschutzrichtlinie (A17), Globale Daten- und Informationsrichtlinie
(A22), Leitfaden zur Zulässigkeit der Nutzung personenbezogener Daten für IT-Entwicklungs- und Testzwecke sowie spezifische Verfahrensanweisungen (Bsp. RD: V9990040
„Datenspeicherung im Fahrzeug“).
Sicherstellung von technischer Compliance in der Software Entwicklung 12Kapitel 03.04| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien bezüglich der Abgrenzung zum
Telekommunikationsgesetz
•Softwarefunktionen sind so zu gestalten, dass keine Relevanz im Sinne des Telekommunikationsgesetzes besteht, da
hieraus besondere Pflichten und gesetzliche Vorgaben entstehen (insb. das Sammeln und Speichern von Verbindungs- und
Kommunikationsdaten, um diese auf Anfrage den Behörden zur Verfügung zu stellen). „Telekommunikationsdienste" sind
i.d.R. gegen Entgelt über Telekommunikationsnetze erbrachte Dienste, die folgende Dienste umfassen:
Internetzugangsdienste, interpersonelle Kommunikationsdienste und Dienste, die ganz oder überwiegend in der Übertragung
von Signalen bestehen. Eine ganz oder überwiegende Signalübertragung liegt dann vor, wenn die inhaltsbezogene
Komponente kein wesentliches Merkmal3 des Dienstes ist. Insbesondere ist die Bereitstellung einer Infrastruktur durch
Vermeidung die Mercedes-Benz AG zur Erbringung von Signalübertragungen im Sinne einer Telekommunikationsleistung kritisch zu
Telekommunikations- hinterfragen (z.B. eine App mit uneingeschränkter Kommunikationsmöglichkeit per vollintegriertem, unbeschränktem Chat).
Relevanz •Werden bei der Software-Entwicklung Funktionalitäten benötigt, die eine Einordnung im Sinne des Telekommunika-
tionsgesetzes erfordern, ist in Absprache mit Software-Architekten zu klären, wie der Dienst durch eine andere
Architektur oder grundsätzliche Umgestaltung außerhalb der TK-Relevanz verbleiben kann.
•Keine ganz oder überwiegende Signalübertragung liegt vor, wenn der angestrebte Zweck des Dienstes über die reine
Anbindung von externem Content hinaus geht und somit einen – insbesondere fahrzeugbezogenen - Mehrwert stiftet
(keine reine Ermöglichung des Dienstes eines Dritten). Dies ist dann der Fall, wenn der Schwerpunkt des Dienstes auf
dem Mercedes-Benz-seitigen Inhalt und nicht ganz oder überwiegend in der Signalübertragung gegebenenfalls zum externen
Content eines Dritten ohne Mercedes-Benz AG Mehrwert liegt.
3. Bei Fragen oder Unklarheiten wenden Sie sich bitte an den zuständigen Entwickler der Mercedes-Benz AG.
Sicherstellung von technischer Compliance in der Software Entwicklung 13Kapitel 04.01 | Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Produktsicherheit
Grundsätzliche Prinzipien
Sicherstellung der Vertraulichkeit,
Integrität, Verfügbarkeit, sowie des Daten- & Software-
Datensicherheit und Abgrenzung
rechtmäßigen und verantwortungs- sicherheit & -verfügbarkeit
Datenschutz
Telekommunikationsgesetz*
vollen Umgangs mit Daten/
Software TK-Recht**
Sicherstellung, dass nur sichere Produkt-
Produkte in den Verkehr gebracht Aktive Sicherheit Passive Sicherheit Gefahrenschutz
werden sicherheit
Sicherstellung, dass regulatorische Emissionen (gesetzl.
Verbrauch, CO2 &
und interne Anforderungen an den Umwelt OBD*
Reichweite
Geräusch limitierte Schad-
Umweltschutz erfüllt werden stoffe) & EMV*
Sicherstellung der
Verwertungsrechte und Schutz- & Ver- Technische Schutz- Softwarespezifische Nichttechnische Geschäfts-
rechtmäßigen Nutzung von rechte (Patente) Urheberrechte Schutzrechte geheimnisse
Software
wertungsrechte
Sicherstellung der Erfüllung von Produkt- Kongruenz beworbener & Konsistenz der
Kundenerwartungen für Funktionen Konsistente Informationen
& Eigenschaften konformität tatsächlicher Funktionen Produktdokumentation
Sicherstellung von technischer Compliance in der Software Entwicklung 14Kapitel 04.02| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für Produktsicherheit (im Allgemeinen)
– (1/2)
Schutz von Personen und Softwarefunktionen müssen die spezifizierten Anforderungen an die Sicherheit zum Schutz des menschlichen Lebens
Umfeld sowie der körperlichen Unversehrtheit erfüllen (diese sind höher zu priorisieren als andere Nützlichkeitserwägungen).
•Softwarefunktionen sind unter Einhaltung des aktuellen Standes von Wissenschaft und Technik zu entwickeln. Mögliche
Gefahren für Leib und Leben sowie Sachen (körperliche Gegenstände) sind mit angemessenen und technisch umsetzbaren
Wissenschaft und Technik Mitteln zu vermeiden. Der Stand der Wissenschaft ergibt sich ständig neu aus einer Gesamtheit von Forschung,
Publikationen und wissenschaftlicher Fachdiskussion (Vorträge auf Fachkongressen, interne Informationen, …) sowie der in
anderen Baureihen und Wettbewerbsfahrzeugen eingesetzter Technologie zum Zeitpunkt der Inverkehrbringung.
•Systemübergreifende Softwarefunktionen sind „End-to-End“ zu betrachten, d.h. über Systemgrenzen und Schnittstellen
Systemgrenzen hinweg von einer Datenerfassung (mit deren möglichen technischen Einschränkungen) über die Verarbeitung bis hin zur
potentiellen erlebbaren Auswirkung und/oder Anzeige gegenüber dem Kunden.
Nachweisführung/ •Wo notwendig, sind einschränkende Systemzustände in Abhängigkeit der Schwere dem Kunden anzuzeigen oder zu
Transparenz protokollieren. Die notwendigen Anzeigen sind in den entsprechenden Fachgremien abzustimmen.
•Softwarefunktionen sind so zu gestalten, dass sicherheitsrelevante Funktionen im Fahrzeug auch ohne externe Anbindung
(z.B. mobile Daten) zur Verfügung stehen oder ein sicherer Zustand erreicht wird. Der plötzliche oder ständige Ausfall der
Unabhängigkeit externen Anbindung darf zu keinen negativen Auswirkungen auf die Beherrschbarkeit der unmittelbaren Weiterfahrt
führen.
•Softwarefunktionen sind so zu gestalten, dass Nutzer rechtzeitig über sicherheitsrelevante Fehlerfälle informiert
Nutzerinformation werden, damit mögliche abwendbare Gefahren für Leib und Leben sowie Sachen so weit wie möglich vermieden werden
können. Diese Informationen müssen auch für den „am geringsten informierten Verbraucher“ verständlich sein.
Sicherstellung von technischer Compliance in der Software Entwicklung 15Kapitel 04.02| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für Produktsicherheit (im Allgemeinen)
– (2/2)
•Softwarefunktionen sind so zu gestalten, dass die Identifikation von kritischen Systemzuständen durch ein sicheres
Sicherheitsmonitoring Monitoring gewährleistet ist.
Risikoreduzierende •Softwarefunktionen sind so zu gestalten, dass sobald kritische Systemzustände erkannt wurden, schnellstmöglich
Schutzmaßnahmen risikoreduzierende Maßnahmen (z.B. eine Anzeige) eingeleitet werden.
•Softwarefunktionen sind unter Berücksichtigung des möglichen vorhersehbaren Fehlgebrauchs zu entwickeln.
Insbesondere ist sicherzustellen, dass:
Vorhersehbarer
– Sicherheitsrelevante Funktionalitäten vom Nutzer nicht versehentlich aktiviert/deaktiviert/genutzt werden (je nach
Fehlgebrauch Ausgestaltung der sicherheitsrelevanten Funktion)
– Nutzer bei Aktivierung oder Deaktivierung von sicherheitsrelevanten Funktionalitäten darüber informiert werden
•Softwarefunktionen sind so zu gestalten, dass die Aufmerksamkeit des Fahrers nicht gefährdend vom Straßenverkehr
Driver Distraction abgelenkt wird (z.B. Driver Distraction und Ergonomie).
Sicherstellung von technischer Compliance in der Software Entwicklung 16Kapitel 04.03| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für aktive und passive Sicherheit
•Softwarefunktionen sind so zu gestalten, dass im gewöhnlichen Gebrauch durch die Interaktion mit dem Fahrzeug keine
Bediensicherheit
abwendbaren Gefahren entstehen können.
•Softwarefunktionen sind so zu gestalten, dass bei gewöhnlichen Gebrauch kurzfristige Systemstörungen ohne negative
Auswirkungen auf die unmittelbare Weiterfahrt beherrschbar bleiben.
Fahrsicherheit
•Softwarefunktionen sind so zu gestalten, dass bei Systemausfall oder bei technisch notwendigen Degradierungen der
Übergang zwischen der Normalfunktion und der Ersatzreaktion beherrschbar erfolgt.
•Softwarefunktionen sind so zu gestalten, dass die körperlichen und geistigen Fähigkeiten des Fahrers zur
Konditionssicherheit
Fahrzeugführung im gewöhnlichen Gebrauch nicht beeinträchtigt werden.
•Softwarefunktionen sind so zu gestalten, dass sicherheitsrelevante Informationen im gewöhnlichen Gebrauch eindeutig
Wahrnehmungssicherheit
wahrgenommen werden können.
•Softwarefunktionen für PRE-SAFE-Systeme sind so zu gestalten, dass im Falle eines erkannten möglichen, unvermeidbaren
Präventiv agieren Unfalls das System auf den bevorstehenden Unfall vorbereitet wird – dazu sind alle geeigneten Sensorinformationen zu
nutzen.
•Softwarefunktionen sind so zu gestalten, dass während des realen Unfallgeschehens der Schutz menschlicher Gesundheit
Unfallsicherheit
nach den technischen Möglichkeiten sichergestellt wird.
•Softwarefunktionen sind so zu gestalten, dass nach einem Unfall so schnell und entsprechend den technischen
Post Crash
Möglichkeiten der Schutz menschlicher Gesundheit sichergestellt wird.
Sicherstellung von technischer Compliance in der Software Entwicklung 17Kapitel 04.04| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für Gefahrenschutz
•Softwarefunktionen sind so zu gestalten, dass mögliche Gefahren für Leib, Leben und Gesundheit durch mechanische
Mechanische Belastung
Belastungen mit angemessenen und technisch umsetzbaren Mitteln vermieden werden (z.B. Einklemmschutz).
•Softwarefunktionen sind so zu gestalten, dass mögliche Gefahren für Leib, Leben und Gesundheit durch thermische
Thermische Belastung
Belastungen mit angemessenen und technisch umsetzbaren Mitteln vermieden werden.
Elektromagnetische •Softwarefunktionen sind so zu gestalten, dass mögliche Gefahren für Leib, Leben und Gesundheit durch
Belastung und elektromagnetische Belastungen (Störaussendung, Störfestigkeit, EMV-U) mit angemessenen und technisch
Verträglichkeit umsetzbaren Mitteln vermieden werden.
•Softwarefunktionen sind so zu gestalten, dass mögliche Gefahren für Leib, Leben und Gesundheit durch toxische
Toxische Belastung
Belastungen mit angemessenen und technisch umsetzbaren Mitteln vermieden werden.
Schutz vor hohen
•Softwarefunktionen sind so zu gestalten, dass mögliche Gefahren für Leib, Leben und Gesundheit durch gefährliche
Spannungen und
Hochspannungen und elektrischen Strömen mit angemessenen und technisch umsetzbaren Mitteln vermieden
elektrischen Strömen (HV-
werden.
Sicherheit)
•Bei der Entwicklung von Softwarefunktionen ist zu berücksichtigen, dass die Bedienung von Fahrzeugfunktionen aus der
Fernsteuerung
Ferne gleiche Auswirkungen auf Aktoren und somit gleiche Relevanz im Sinne des Gefahrenschutzes impliziert.
Sicherstellung von technischer Compliance in der Software Entwicklung 18Kapitel 05.01 | Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Umwelt
Grundsätzliche Prinzipien
Sicherstellung der Vertraulichkeit,
Integrität, Verfügbarkeit, sowie des Daten- & Software-
Datensicherheit und Abgrenzung
rechtmäßigen und verantwortungs- sicherheit & -verfügbarkeit
Datenschutz
Telekommunikationsgesetz*
vollen Umgangs mit Daten/
Software TK-Recht**
Sicherstellung, dass nur sichere Produkt-
Produkte in den Verkehr gebracht Aktive Sicherheit Passive Sicherheit Gefahrenschutz
werden sicherheit
Sicherstellung, dass regulatorische Emissionen (gesetzl.
Verbrauch, CO2 &
und interne Anforderungen an den Umwelt OBD*
Reichweite
Geräusch limitierte Schad-
Umweltschutz erfüllt werden stoffe) & EMV*
Sicherstellung der
Verwertungsrechte und Schutz- & Ver- Technische Schutz- Softwarespezifische Nichttechnische Geschäfts-
rechtmäßigen Nutzung von rechte (Patente) Urheberrechte Schutzrechte geheimnisse
Software
wertungsrechte
Sicherstellung der Erfüllung von Produkt- Kongruenz beworbener & Konsistenz der
Kundenerwartungen für Funktionen Konsistente Informationen
& Eigenschaften konformität tatsächlicher Funktionen Produktdokumentation
* Siehe Begriffsdefinition im Backup Sicherstellung von technischer Compliance in der Software Entwicklung 19Kapitel 05.02| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für Onboard Diagnose (OBD) - (1/2)
Schutz von Gesundheit •OBD-Diagnosen sind grundsätzlich so zu gestalten, dass OBD relevante Fehlfunktionen zielsicher und rechtzeitig erkannt
und Umwelt sowie angezeigt werden.
•Softwarefunktionen müssen durchgängig die gesetzlichen Anforderungen an die OBD erfüllen, ohne dazu zu führen, dass
Stellenwert/Priorität, andere zwingende Vorgaben (etwa bzgl. Emissionen oder Geräuschemissionen) nicht eingehalten werden. Dies ist sicherzustellen,
Wissenschaft und auch wenn es zu Lasten von Komfort- oder Performanceanforderungen geht.
Technik •Bei Unklarheiten oder Zweifeln an der Erfüllung der gesetzlichen Vorgaben, ist frühzeitig eine Absprache mit der
Zertifizierung erforderlich.
•Softwarefunktionen sind unter Einhaltung des aktuellen Standes von Wissenschaft und Technik zu entwickeln.
•Die Freigabebedingungen der OBD-Diagnosen sind auf den realen Fahrbetrieb unter den gesetzlich definierten
Betriebsbedingungen auszulegen und müssen gleichzeitig im gesetzlich definierten Zyklus durchlaufen werden.
Test-/
•Im realen Fahrbetrieb sind die gesetzlich definierten Ablaufhäufigkeiten der OBD-Diagnosen sicherzustellen.
Zykluserkennung*
•Sollte der Durchlauf der OBD-Diagnose im gesetzlich definierten Zyklus aus technischen Gründen nicht möglich sein, ist eine
Absprache mit der Zertifizierung erforderlich.
•OBD-Diagnosen sind auf Basis physikalischer Einschaltbedingungen zu aktivieren und deaktivieren.
•OBD-Diagnosen sind so zu gestalten, dass ein potentieller Testzyklusbezug von Zählern, Timern (z.B. Zeit nach Motorstart),
integrierten Parametern, irreversiblen Zustandsautomaten/Speicherelementen nur für unbedingt notwendige und
Physikalische
begründbare (die jeweilige Begründung ist in geeigneter Form zu dokumentieren) Veränderungen im Systemverhalten verwendet
Orientierung
werden.
•OBD-Diagnosen sind bzgl. ihrer Einschalt- und Überwachungsbereiche so aufeinander abzustimmen, dass keine
Überwachungslücken entstehen.
* Siehe Begriffsdefinition im Backup Sicherstellung von technischer Compliance in der Software Entwicklung 20Kapitel 05.02| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für Onboard Diagnose (OBD) - (2/2)
•Deaktivierungsbedingungen von OBD-Diagnosen sind reversibel zu gestalten. Sofern die physikalischen Einschaltbedingungen
Betriebsbedingungen erfüllt sind, muss die OBD-Diagnose aktiv sein.
•OBD-Diagnosen, die dies nicht erfüllen können (once per trip), sind mit der Zertifizierung abzustimmen.
•Intrusive OBD-Diagnosen sind generell zu vermeiden und nur nach Absprache mit einer Typgenehmigungsbehörde* unter
Einbeziehung der Zertifizierung möglich. In jedem Fall ist ein vollständiges Durchlaufen einer intrusiven OBD-Diagnose in den
gesetzlich definierten Abgastestzyklen erforderlich, sofern keine anderweitige Vorgabe/Anordnung einer Behörde vorliegt.
•OBD-Diagnosestrategien müssen ggf. mit der Behörde abgestimmt und im Rahmen einer Vorabstrategie-Genehmigung durch die
Behörde geprüft werden, deshalb sind diese entwicklungsbegleitend mit der Zertifizierung abzustimmen.
Diagnosegestaltung
•OBD-Diagnosen und Adaptionen sind systemübergreifend abzustimmen, um Überwachungslücken prinzipiell auszuschließen.
•Alle Eingangssignale einer OBD-Diagnose müssen selbst OBD-seitig überwacht werden.
•Sperrungen von OBD-Diagnosen durch nicht OBD-relevante Funktionen sind auszuschließen (sog. MIL-Verdeckungen).
•Softwarefunktionen von Steuergeräten, bei denen eine OBD-Relevanz zu erwarten ist (z.B. aufgrund von geplanten
Gesetzesänderungen), sind OBD-konform auszulegen.
•Zertifizierungsrelevante Dokumente sind inhaltlich korrekt, unmissverständlich, vollständig und unter Berücksichtigung
der rechtlichen Vorgaben anzufertigen und zu prüfen.
•Mögliche Auswirkungen von Software-Änderungen auf zertifizierungsrelevante Dokumentationen sind zu berücksichtigen
Dokumentation
und Anpassungen in den entsprechenden Dokumenten sind vorzunehmen und im Vorfeld der Software-Implementierung mit der
Zertifizierung abzustimmen.
•Softwarefunktionen inklusive deren Bedatungen sind für einen sachkundigen Dritten logisch nachvollziehbar darzustellen.
*Nachfolgend wird für eine marktspezifische „Typgenehmigungsbehörde“ der Begriff „Behörde“ verwendet. Sicherstellung von technischer Compliance in der Software Entwicklung 21Kapitel 05.03| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für verbrauchsrelevante Software-
Funktionen (Kraftstoff & elektrische Energie) - (1/2)
Schutz von Gesundheit •Softwarefunktionen kraftstoffverbrauchsrelevanter Fahrzeugsysteme sind grundsätzlich so zu gestalten, dass sie den Schutz
und Umwelt von Gesundheit und Umwelt gewährleisten.
•Die verbrauchsbeeinflussende Wirkung (Kraftstoff & elektrische Energie) einer Softwarefunktion ist unter Beibehaltung der
Stellenwert/Priorität gesetzlichen Rahmenbedingungen so zu gestalten, dass sie in einem angemessenen Verhältnis zum Kundennutzen (Komfort-
und Performanceanforderungen) steht.
•Softwarefunktionen sind testzyklus- und prüfstandsunabhängig zu gestalten und es darf keine direkte oder indirekte
Test-/Zykluserkennung Erkennung von Prüfungsrandbedingungen erfolgen.
•Es darf keine Umschaltung auf andere Betriebsmodi basierend auf dem Erkennen von Prüfungsrandbedingungen erfolgen.
•Eine Änderung der Betriebsstrategie durch Softwarefunktionen ist nur erlaubt, wenn diese physikalisch begründbar,
bedarfsgerecht und energetisch sinnvoll ist.
•Bei Bedarf können AES-Begründungen für Softwarefunktionen, die eine Änderung der Betriebsstrategie hervorrufen,
entwicklungsbegleitend unter Koordination der Zertifizierung von einer Behörde geprüft und genehmigt werden.
Physikalische •Bei Bedarf können neue AES Softwarefunktionen entwicklungsbegleitend unter Koordination der Zertifizierung von der
Orientierung Behörde geprüft und genehmigt werden.
•Softwarefunktionen sind so zu gestalten, dass ein potentieller Testzyklusbezug von Zählern, Timern (z.B. Zeit nach Motorstart),
integrierten Parametern, Speicherelementen oder weiteren Parametern mit potentiellem Testzyklusbezug nur für unbedingt
notwendige und begründbare (die jeweilige Begründung ist in geeigneter Form zu dokumentieren) Veränderungen im
Systemverhalten verwendet werden - ggfs. vor der Verwendung die Zertifizierung und technische Compliance konsultieren.
Sicherstellung von technischer Compliance in der Software Entwicklung 22Kapitel 05.03| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für verbrauchsrelevante Software-
Funktionen (Kraftstoff & elektrische Energie) - (2/2)
•Softwarefunktionen sind, soweit technisch möglich, bezüglich Aktivierungs- und Deaktivierungsbedingungen reversibel zu
Reversibilität
gestalten.
•Softwarefunktionen sind so zu gestalten, dass die CO2-Maßnahmen in ihrer Wirkung unter realem Fahrbetrieb möglichst
vollständig energetisch ausgenutzt werden.
Normale •Kraftstoffverbrauchserhöhende Softwarefunktionen sind nur unter festgelegten Ausnahmen zulässig.
Betriebsbedingungen •Energieverbrauchserhöhende Softwarefunktionen sind auf ihre Auswirkung hinsichtlich der zertifizierten Reichweite und
des zertifizierten Stromverbrauchs zu prüfen. Softwarefunktionen sind so zu gestalten, dass das Verhältnis zwischen
Energieverbrauch und Reichweite zum Kundennutzen (Komfort- und Performanceanforderungen) angemessen ist.
•Zertifizierungsrelevante Dokumente sind inhaltlich korrekt, unmissverständlich, vollständig und unter Berücksichtigung
Dokumentation
der rechtlichen Vorgaben anzufertigen und zu prüfen.
Sicherstellung von technischer Compliance in der Software Entwicklung 23Kapitel 05.04| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für geräuschrelevante Software-
Funktionen - (1/2)
Schutz von Gesundheit •Softwarefunktionen geräuschrelevanter Fahrzeugsysteme sind so zu gestalten, dass sie den Schutz von Gesundheit und
und Umwelt Umwelt gewährleisten.
•Softwarefunktionen müssen die gesetzlichen Anforderungen an Geräuschemissionen erfüllen, ohne dazu zu führen, dass
Stellenwert/Priorität andere zwingende Vorgaben (etwa bzgl. OBD oder Emissionen) nicht eingehalten werden. Dies ist sicherzustellen, auch wenn es
zu Lasten von Komfort- oder Performanceanforderungen geht.
•Softwarefunktionen sind im Hinblick auf den realen Fahrbetrieb zu gestalten und es darf keine Erkennung von
Testerkennung
Prüfungsrandbedingungen erfolgen.
•Softwarefunktionen sind auf Basis physikalischer Größen zu entwickeln und auszulegen.
Physikalische
•Physikalische Begründungen von Softwarefunktionen müssen ggf. mit der Behörde abgestimmt und von dieser anerkannt werden,
Orientierung
deshalb sind diese entwicklungsbegleitend mit der Zertifizierung abzustimmen.
•Softwarefunktionen sind, soweit technisch möglich, bezüglich Aktivierungs- und Deaktivierungsbedingungen reversibel zu
Reversibilität
gestalten.
•Softwarefunktionen geräuschrelevanter Fahrzeugsysteme (z.B. Abgasklappensteuerung) sind so zu gestalten, dass das Fahrzeug
Betriebsmodi die relevanten Zertifizierungswerte in allen Betriebsmodi einhält - potentielle Abweichungen sind mit Zertifizierung und
technischer Compliance abzustimmen.
Sicherstellung von technischer Compliance in der Software Entwicklung 24Kapitel 05.04| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für geräuschrelevante Software-
Funktionen - (2/2)
•Geräuschmodulationen7 (z.B. durch Aktuatoren/Soundgenerator) sind nur unter bestimmten Vorrausetzungen gesetzlich
Geräuschmodulationen zulässig. Das modulierte Geräuschverhalten muss alle gesetzlichen Anforderungen erfüllen8. Je nach anzuwendender Vorschrift
darf darüber hinaus keine Erhöhung des Geräuschpegels erfolgen9.
Teilschallquellen •Einflüsse auf das Abgasmündungsgeräusch müssen berücksichtigt werden, um Geräuschanforderungen zu erfüllen.
•Zertifizierungsrelevante Dokumente sind inhaltlich korrekt, unmissverständlich, vollständig und unter Berücksichtigung
Dokumentation
der rechtlichen Vorgaben anzufertigen und zu prüfen.
7. Besondere Anforderungen gelten an Fahrzeuge, die rein elektrisch fahren können | 8. Siehe hierzu Fassung ECE R51.03 Erg.04 in Verbindung mit UN-ECE Informal document GRB-68-03.
9. Beispielsweise unter UN R 51.02
Sicherstellung von technischer Compliance in der Software Entwicklung 25Kapitel 05.05| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für emissionsrelevante (gesetzl.
limitierte Schadstoffe) & EMV-relevante* Software-Funktionen - (1/3)
Schutz von Gesundheit •Softwarefunktionen emissionsrelevanter Fahrzeugsysteme sind so zu gestalten, dass sie den Schutz von Gesundheit und
und Umwelt Umwelt gewährleisten.
•Softwarefunktionen müssen die gesetzlichen Anforderungen an Emissionen erfüllen, ohne dazu zu führen, dass andere
Stellenwert/Priorität zwingende Vorgaben (etwa bzgl. OBD oder Geräuschemissionen) nicht eingehalten werden. Dies ist sicherzustellen, auch wenn es
zu Lasten von Komfort- oder Performanceanforderungen geht.
•Softwarefunktionen sind testzyklus- und prüfstandsunabhängig zu gestalten und es darf keine direkte oder indirekte
Test-/Zykluserkennung
Erkennung von Prüfungsrandbedingungen erfolgen.
•Softwarefunktionen sind auf Basis physikalischer Größen zu entwickeln und auszulegen.
•Softwarefunktionen sind so zu gestalten, dass Zähler, Timer (z.B. Zeit nach Motorstart), integrierte Parameter,
Speicherelemente, Ansteuerungen oder weitere Parameter mit potentiellem Testzyklusbezug nur für unbedingt notwendige
Physikalische
und begründbare (die jeweilige Begründung ist in geeigneter Form zu dokumentieren) Veränderungen im Systemverhalten
Orientierung
verwendet werden – ggfs. vor der Verwendung die Zertifizierung und technische Compliance konsultieren.
•Bei Bedarf können AES-Begründungen für Softwarefunktionen, die eine Änderung des Systemverhaltens hervorrufen,
entwicklungsbegleitend unter Koordination der Zertifizierung von der Behörde geprüft und genehmigt werden.
•Softwarefunktionen sind, soweit technisch möglich und sinnvoll, bezüglich Aktivierungs- und Deaktivierungsbedingungen
Reversibilität reversibel zu gestalten, sodass beispielsweise das Hin- und Herwechseln zwischen unterschiedlichen Betriebsmodi
gewährleistet ist.
*Software-Funktionen mit Auswirkungen auf die elektromagnetische Verträglichkeit (EMV) der Komponente Sicherstellung von technischer Compliance in der Software Entwicklung 26Kapitel 05.05| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für emissionsrelevante (gesetzl.
limitierte Schadstoffe) & EMV-relevante* Software-Funktionen - (2/3)
Normale
•Softwarefunktionen sind so zu gestalten, dass die Maßnahmen in ihrer Wirkung physikalisch sinnvoll und begründbar sind.
Betriebsbedingungen
•Zertifizierungsrelevante Dokumente sind inhaltlich korrekt, unmissverständlich, vollständig und unter Berücksichtigung
der rechtlichen Vorgaben anzufertigen und zu prüfen.
•Mögliche Auswirkungen von Software-Änderungen auf zertifizierungsrelevante Dokumentationen sind mit der
Zertifizierung abzustimmen.
Gilt nur für emissionsrelevante Software-Funktionen:
Dokumentation
•Bei Bedarf können AES-Begründungen für Softwarefunktionen entwicklungsbegleitend unter Koordination der
Zertifizierung von der Behörde geprüft und genehmigt werden.
•Softwarefunktionen inklusive deren Bedatungen sind für einen sachkundigen Dritten logisch nachvollziehbar darzustellen.
•Für Softwarefunktionen, bei denen die Zulässigkeit anhand ihres Vorkommens in gesetzlich vorgegebenen Testprozeduren
begründet wird, müssen Belege in Form von Testdaten oder ingenieurtechnischen Begründungen vorliegen.
•Softwarefunktionen zum Bauteilschutz sind physikalisch zu begründen.
•Die Grenzen sind so restriktiv zu wählen, dass bei Überschreitung die direkten negativen Auswirkungen auf das Bauteil klar
belegbar sind.
•Softwarefunktionen zum Bauteilschutz sind so zu gestalten, dass diese nur in der geringstmöglichen Anzahl von
Bauteilschutz Fahrsituationen aktiv werden. Falls eine Softwarefunktion zum Bauteilschutz in einem weiten Bereich von Fahrsituationen aktiv
wird, ist der Entwurf/die Robustheit des Gesamtsystems zu überprüfen.
•Die Bauteilschutzbegründung muss durch Bauteildatenblätter (Lieferant) oder Messdaten belegbar sein.
•Bei Bedarf können AES-Begründungen für den Bauteilschutz entwicklungsbegleitend unter Koordination der
Zertifizierung von der Behörde geprüft und genehmigt werden.
*Software-Funktionen mit Auswirkungen auf die elektromagnetische Verträglichkeit (EMV) der Komponente Sicherstellung von technischer Compliance in der Software Entwicklung 27Kapitel 05.05| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für emissionsrelevante (gesetzl.
limitierte Schadstoffe) & EMV-relevante* Software-Funktionen - (3/3)
•Softwarefunktionen sind so zu gestalten, dass die emittierten elektromagnetischen Felder der zugehörigen elektrischen
EMV-Emissionen &
Fahrzeugsysteme den geltenden EMV-Zertifizierungsvorschriften (bspw. ECE-R10; GB/T [China]) und EMV-Normen (inkl. MBN
Störfestigkeit:
10284) entsprechen. Beeinflussungen von Spannungen und Strömen durch geänderte Ansteuerungen (z.B. die Generierung
Sicherstellung der
von Hochfrequenz-Anteilen durch geänderte Flanken und Pulsweiten) sind zu berücksichtigen.
elektromagnetisch
•Veränderungen im Ansprechverhalten von Fehler-Diagnosen sind so zu gestalten, dass sie den Anforderungen der EMV
verträglichen Funktion
genügen.
elektrischer
Fahrzeugsysteme
*Software-Funktionen mit Auswirkungen auf die elektromagnetische Verträglichkeit (EMV) der Komponente Sicherstellung von technischer Compliance in der Software Entwicklung 28Kapitel 06.01 | Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Schutz- und Verwertungsrechte
Grundsätzliche Prinzipien
Sicherstellung der Vertraulichkeit,
Integrität, Verfügbarkeit, sowie des Daten- & Software-
Datensicherheit und Abgrenzung
rechtmäßigen und verantwortungs- sicherheit & -verfügbarkeit
Datenschutz
Telekommunikationsgesetz*
vollen Umgangs mit Daten/
Software TK-Recht**
Sicherstellung, dass nur sichere Produkt-
Produkte in den Verkehr gebracht Aktive Sicherheit Passive Sicherheit Gefahrenschutz
werden sicherheit
Sicherstellung, dass regulatorische Emissionen (gesetzl.
Verbrauch, CO2 &
und interne Anforderungen an den Umwelt OBD*
Reichweite
Geräusch limitierte Schad-
Umweltschutz erfüllt werden stoffe) & EMV*
Sicherstellung der
Verwertungsrechte und Schutz- & Ver- Technische Schutz- Softwarespezifische Nichttechnische Geschäfts-
rechtmäßigen Nutzung von rechte (Patente) Urheberrechte Schutzrechte geheimnisse
Software
wertungsrechte
Sicherstellung der Erfüllung von Produkt- Kongruenz beworbener & Konsistenz der
Kundenerwartungen für Funktionen Konsistente Informationen
& Eigenschaften konformität tatsächlicher Funktionen Produktdokumentation
Sicherstellung von technischer Compliance in der Software Entwicklung 29Kapitel 06.02| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für softwarerelevante Schutz- und
Verwertungsrechte (1/2)
•Softwarebasierte Funktionen* sind so zu gestalten, dass keine Patente Dritter verletzt werden. Zu vermeiden ist daher
insbesondere:
Technische Schutzrechte –Das gezielte Rekonstruieren bzw. Nachahmen patentrechtlich geschützter Ideen und Algorithmen.
(Patente)13 –Die Umsetzung der softwarebasierten Funktionen ohne Reflektion, ob die umzusetzende Idee bzw. der Algorithmus
patentrechtlich geschützt ist.
–Das Nutzen von Standards, die durch Patente geschützt sein können, ohne Reflektion einer Berechtigung.
•Softwarebasierte Funktionen sind so zu gestalten, dass keine Urheberrechte Dritter verletzt werden. Zu vermeiden ist
daher insbesondere:
–Das Kopieren, Verändern, Verteilen, Lizenzieren oder Verkaufen von Software ohne urheberrechtliche Erlaubnis (z.B.
Frameworks Dritter aus Internetportalen).
–Das gezielte Rekonstruieren bzw. Nachahmen von Software, wie z.B. durch unautorisiertes Übersetzen des Codes in eine
Softwarespezifische
andere Programmiersprache.
Urheberrechte
–Die Verwendung von Open-Source-Software und Firmware ohne Einhaltung der entsprechenden Lizenzbedingungen.
–Die Verwendung von Software mit starkem *Copyleft (wie z.B. General Public Licence), da dies die Verpflichtung zur
Veröffentlichung der eigenen Software impliziert.
–Die Verwendung von Software, deren Lizenzen kein ganzheitliches Verständnis der Software erlauben, da nur auf
einzelne Bestandteile zugegriffen werden kann.
* Siehe Begriffsdefinition im Backup Sicherstellung von technischer Compliance in der Software Entwicklung 30Kapitel 06.02| Software-Compliance Guide extern 2021| gültig ab 01.07.2021
Technische Compliance Prinzipien für softwarerelevante Schutz- und
Verwertungsrechte - (2/2)
•Softwarebasierte Funktionen sind so zu gestalten, dass keine Markenzeichen Dritter verletzt werden. Zu vermeiden ist
daher insbesondere:
Nichttechnische
–Die Verwendung von Marken-, Produkt-, und Personennamen, Abkürzungen, Abbildungen, Hörzeichen etc., ohne
Schutzrechte (Marken,
deren markenrechtlichen Schutz zu berücksichtigen.
Designs, Domains)
–Die Benennung von Funktionalitäten, Ideen, Diensten etc. ohne die Namensgebung auf Markenrechte Dritter zu prüfen.
Die Prüfung ist über trademarks@daimler.com zu veranlassen.
•Softwarebasierte Funktionen sind so zu gestalten, dass keine Geschäftsgeheimnisse Dritter verletzt werden und dass
keine Geschäftsgeheimnisse von Daimler nach außen gelangen. Zu vermeiden ist dabei insbesondere:
–Die unzureichende Absicherung (z.B. fehlende Verschlüsselung, unzureichende Speicherkonzepte) von Software und
Daten Dritter, welche im Rahmen von Kollaborationen verwendet werden.
Geschäftsgeheimnisse
–Die Missachtung von mit Dritten vereinbarten Rahmenbedingungen, insbesondere Vertraulichkeitsvereinbarungen (z.B.
kann ein Code intern verwendet und verändert werden, aber eine Weitergabe untersagt sein).
–Die unzureichende Absicherung (z.B. fehlende Verschlüsselung, unzureichende Speicherkonzepte) interner Software
und Daten, die als Geschäftsgeheimnis klassifiziert sind.
Sicherstellung von technischer Compliance in der Software Entwicklung 31Sie können auch lesen
