{"id":7950,"date":"2025-11-29T08:07:00","date_gmt":"2025-11-29T07:07:00","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=7950"},"modified":"2026-02-13T06:52:33","modified_gmt":"2026-02-13T05:52:33","slug":"metrics-driven-process-development-in-the-context-of-future-networked-mobility","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/","title":{"rendered":"Metrics-driven process development in the context of future connected mobility"},"content":{"rendered":"

Ein Framework zur Risikobewertung von Fahrzeug-Funktionen<\/h2>\n

Autoren: Christopher Kugler, Stefan Kowalewski, Lehrstuhl Informatik 11 \u2013 Embedded Software, RWTH Aachen University; German Baca Espinoza, Ralf Maquet, Jiju Vadakkepattath, Dirk Macke, Johannes Richenhagen,\u00a0FEV Europe GmbH<\/p>\n

Beitrag – Embedded Software Engineering Kongress 2017<\/h3>\n

Mobilit\u00e4t ver\u00e4ndert sich disruptiv: Neue Themenkomplexe wie Fahrzeugvernetzung und hochintelligente Assistenzsysteme stellen hohe Qualit\u00e4tsanforderungen an SW-Produkte bei steigender Komplexit\u00e4t. Folglich m\u00fcssen bestehende Entwicklungsprozesse kontinuierlich verbessert werden, um dem Zeit- und Kostenrahmen in Projekten gerecht zu werden. In dieser Arbeit werden qualitative, metriken-basierte Meilensteine definiert, die einen reibungslosen \u00dcbergang zwischen Entwicklungsphasen sicherstellen sollen. Ein Rahmenwerk zur Risikobewertung von Fahrzeug-Funktionen wird vorgeschlagen, welches im Sinne des risikobasierten Testens zur Steuerung des Testumfangs genutzt werden kann. Es werden Risikofaktoren identifiziert, die eine Anwendung im Kontext vernetzter Mobilit\u00e4t erlauben. Zuvor definierte Metriken aus fr\u00fchen Entwicklungsphasen flie\u00dfen in die Bewertung ein und gew\u00e4hrleisten ein Mindestma\u00df an Objektivit\u00e4t. Das Rahmenwerk wird anhand einer Fallstudie evaluiert und der operative Mehrwert aufgezeigt.<\/strong><\/p>\n

1. Einf\u00fchrung<\/h2>\n

Hohe Komplexit\u00e4t und Qualit\u00e4tsanforderungen, sowie vergleichsweise geringe Kosten- und Zeitbudgets sind Herausforderungen bei der Entwicklung von automobilen Steuerungssystemen. Insbesondere eine steigende Anzahl von Anforderungen f\u00fcr Fahrerassistenzsysteme (Advanced Driver Assistance Systems – ADAS) und f\u00fcr automatisiertes Fahren (Automated Driving -AD) erfordern technologische Innovationen und einen agilen Entwicklungsprozess. Vor allem im interdisziplin\u00e4ren Bereich der Software Entwicklung bringen vernetzte Steuerger\u00e4te neue Themengebiete wie Cyber-Security und Robustheit gegen\u00fcber externen St\u00f6rfaktoren ins Spiel.<\/p>\n

Eine besondere Rolle kommt automobilen Dienstleistern zu, die auf Grund von stetig wechselnden Projektrahmenbedingungen Methoden entwickeln m\u00fcssen, um auf sich kurzfristig \u00e4ndernde Anforderungen reagieren zu k\u00f6nnen. So wird regelm\u00e4\u00dfig die Nutzung externer Prozessabl\u00e4ufe und Tools vorausgesetzt. Entsprechend schwierig wird die Definition und Verankerung geeigneter Prozesse beim Dienstleister, die dabei helfen k\u00f6nnen, den Entwicklungshub m\u00f6glichst effizient zu gestalten.<\/p>\n

Eine bew\u00e4hrte Praktik, um prozessseitige Flexibilit\u00e4t zu erm\u00f6glichen und wettbewerbsf\u00e4hige Produkte zu entwickeln, ist der Einsatz von Qualit\u00e4tsschranken (eng.: Quality Gates) im Entwicklungsprozess. Die grundlegende Idee ist mit dem Prinzip einer Fabrik vergleichbar (Abb. 1 im\u00a0P DF<\/a>), wo ein folgender Verarbeitungsschritt erst startet, nachdem die definierte Qualit\u00e4t des Werkst\u00fccks sichergestellt worden ist.<\/p>\n

Zur Definition geeigneter Qualit\u00e4tsschranken im Kontext automobiler Softwareentwicklung bieten sich eine Vielzahl von Metriken an, deren Aussagekraft allerdings von unternehmensspezifischen Strukturen und Zielen abh\u00e4ngt.<\/p>\n

In den folgenden Kapiteln werden zun\u00e4chst beispielhaft Qualit\u00e4tsschranken f\u00fcr fr\u00fche Entwicklungsphasen \u2013 der Anforderungsdefinition und der Architekturentwicklung \u2013 eingef\u00fchrt und deren Nutzen er\u00f6rtert. Im Anschluss wird ein Rahmenwerk zur Risikobewertung von Fahrzeug-Funktionen vorgeschlagen, das auf diesen Metriken aufbaut und einen wesentlichen Beitrag zur Praxis der risikobasierten Qualit\u00e4tssicherung leisten kann.<\/p>\n

2. Metriken-getriebene Softwareprozesse<\/h2>\n

Metriken-getriebene Prozesse sind ein effektives Mittel, um typische Herausforderungen der Softwareentwicklung beherrschbar zu machen. Folgende Anforderungen an einen Prozess, die eine hohe Wertigkeit bedingen, sollen herausgestellt werden:<\/p>\n

    \n
  1. Agile Methoden in der Prozessaus\u00fcbung mit wohldefinierten Schnittstellen zu Kundenprozessen<\/li>\n
  2. Mess- und bewertbare Prozessergebnisse<\/li>\n
  3. Risikobewusste Steuerung der Prozesse (Robustheit gegen \u00e4u\u00dfere Einfl\u00fcsse, Flexibilit\u00e4t im Prozess, um (sich \u00e4ndernde) Schwerpunkte zu setzen)<\/li>\n
  4. Geeignete Komplexit\u00e4tsreduktion der vorliegenden Aufgabe (beispielsweise durch Unterteilung in mehrere Schritte)<\/li>\n<\/ol>\n

    Im Kontext von Qualit\u00e4tsschranken liegt hier vor allem Punkt 2) im Fokus, wobei Kapitel 3 mit dem Risiko-basierten Rahmenwerk im Wesentlichen Punkt 3) adressiert.<\/p>\n

    Zur Gew\u00e4hrleistung einer hohen Softwarequalit\u00e4t ist es sinnvoll, bereits Artefakte aus fr\u00fchen Entwicklungsphasen nach strengen Qualit\u00e4tskriterien zu bewerten um so potentiellen zuk\u00fcnftigen Problemen vorzubeugen. Dies betrifft vor allem funktionale und nicht-funktionale Anforderungen, die als Grundlage der Software-Entwicklung dienen. Ein weiterer zentraler Aspekt ist die strukturelle Auslegung des Systems im Rahmen einer Software-Architektur und die damit einhergehende Zerlegung in Software-Komponenten, welche ma\u00dfgeblichen Einfluss auf notwendige Schnittstellen und umzusetzende Funktionslogik nimmt.<\/p>\n

    2.1 Qualit\u00e4tsschranken f\u00fcr Anforderungen<\/h3>\n

    Qualit\u00e4tsschranken k\u00f6nnen \u00fcber aussagekr\u00e4ftige Metriken, sogenannte Key Performance Indikatoren (KPIs), realisiert werden. Im Bereich der Spezifikation und Entwicklung von Anforderungen sind in der Literatur vielf\u00e4ltige KPIs identifiziert und er\u00f6rtert worden (vgl. [SM07], [He10]). Angelehnt an diese werden in [No17] drei wesentliche Anforderungsaspekte betrachtet, die eine qualitative Aussage \u00fcber entstehende Anforderungsdokumente erm\u00f6glichen und als Basis f\u00fcr weitere Ausf\u00fchrungen in diesem Beitrag dienen.<\/p>\n

    1. Anforderungsreife –\u00a0beispielsweise bewertet \u00fcber:<\/em><\/p>\n

    a. Erf\u00fcllungsgrad der SOPHIST Anforderungsschablone [Ge08]
    \nb. Anforderungs-Komplexit\u00e4t<\/p>\n

    2. Anforderungsabdeckung\u00a0\u2013 im Wesentlichen bewertet \u00fcber:<\/em><\/p>\n

    a. Abdeckungsgrad der Kundenanforderungen (alternativ: Konvergenzrate zwischen Lasten- und Pflichtenheft)<\/p>\n

    3. Anforderungstesttiefe \u2013\u00a0hier nicht im Fokus, da Ursprung in sp\u00e4teren Entwicklungsphasen<\/em><\/p>\n

    Detaillierte Definitionen und weitere Ausf\u00fchrungen zu den genannten Metriken sind in [No17] zu finden. Abb. 2 (s.\u00a0PDF<\/a>) veranschaulicht dies grafisch. Die Metriken k\u00f6nnen regelm\u00e4\u00dfig f\u00fcr Anforderungsdokumente erhoben werden und dabei helfen, deren Qualit\u00e4t zu bewerten. Der Start weiterer Entwicklungsschritte, die auf diesen Anforderungen basieren ist nur dann sinnvoll, wenn in den definierten KPIs ein vorgegebener Schwellwert \u00fcberschritten wird.<\/p>\n

    2.2 Qualit\u00e4tsschranken f\u00fcr Architekturartefakte<\/h3>\n

    Ein zentrales Element der fr\u00fchen Software-Entwicklung ist die Software-Architektur und die damit verwandten Artefakte (Schnittstellendefinition, Software-Komponenten). Hier besteht die Herausforderung darin, die Komplexit\u00e4t der Architektur und auch der Komponenten m\u00f6glichst gering zu halten, um Wartbarkeit, Testbarkeit und Analysierbarkeit zu gew\u00e4hrleisten. In [Ve17] werden diesbez\u00fcglich verschiedene Komplexit\u00e4tsmetriken f\u00fcr Software-Komponenten er\u00f6rtert und verglichen.<\/p>\n

    Im Fokus stehen die Anzahl der externen und internen Schnittstellen einer Komponente und die Anzahl der in einer Komponente jeweils umgesetzten Funktionen. Diese Informationen werden schlussendlich zu einem KPI „Software Component Complexity“ aggregiert (vgl. Abb. 3, s.\u00a0PDF<\/a>). In der Entwicklung kann nun \u2013 basierend auf unternehmensspezifischen Parametern \u2013 ein Schwellwert f\u00fcr die maximal tolerierte Komplexit\u00e4t festgelegt werden. Architekturelemente, die diesen Schwellwert \u00fcberschreiten, m\u00fcssen hinsichtlich Modularit\u00e4t untersucht und weiter separiert werden.<\/p>\n

    3 Metriken-basiertes Rahmenwerk zur Risikobewertung von Fahrzeug-Funktionen im Kontext der Qualit\u00e4tssicherung<\/h2>\n

    Die Grundidee der risikobasierten Qualit\u00e4tssicherung ist die Erkenntnis, dass in der Realit\u00e4t unter gegebenen Projektrahmenbedingungen eine 100%ige Absicherung (Verifikation & Validierung) des Produkts nicht m\u00f6glich ist [PR12], [Si11]. Daher wird auf ein Priorisierungsschema zur\u00fcckgegriffen, das sich im Wesentlichen auf bezugsspezifische Risikowerte st\u00fctzt. Abb. 4 (s.\u00a0PDF<\/a>) beschreibt dieses Vorgehen.<\/p>\n

    Ans\u00e4tze, den Prozess der Risikobeurteilung \u00fcber den Einsatz von spezifischen Kenn- und Ma\u00dfzahlen zu objektivieren, werden unter anderem in [No00], [Be99] und [SM07] untersucht. Benlarbi et. al. besch\u00e4ftigen sich im Wesentlichen mit Code Metriken [Be99], wohingegen Nogueira et. al. ausschlie\u00dflich Projektrisiken untersucht [No00], welche nicht im Fokus dieses Beitrags liegen. Die hier im Folgenden betrachteten Risiken sind produktbezogen und treffen prim\u00e4r eine Aussage \u00fcber technische Eigenschaften der Betrachtungseinheit. Ein Ansatz, der dem Vorgehen in diesem Beitrag \u00e4hnelt, ist durch Stallbaum et. al. in [SM07] er\u00f6rtert worden: Hier werden Anforderungsmetriken zur automatisieren Risikobewertung von Anforderungsdokumenten, beispielsweise Use-Case Definitionen, herangezogen. Im Vergleich gibt es drei wesentliche Unterschiede zu dem hier vorgestellten Rahmenwerk:<\/p>\n

      \n
    1. Unterschiedliche Betrachtungseinheit: Fokus auf systemweiten Funktionen anstatt auf einzelne Use-Cases<\/li>\n
    2. Einbezug von Architekturmetriken als zus\u00e4tzlicher Bewertungsfaktor<\/li>\n
    3. Einbezug von qualitativen Bewertungsfaktoren (Expertenbeurteilung)<\/li>\n<\/ol>\n

      Das Ziel des hier beschriebenen Rahmenwerks ist die Herleitung von funktionsspezifischen Risikowerten basierend auf den in Kapitel 2 vorgestellten Metriken, sowie weiteren ad-hoc definierten Einflussfaktoren. Dazu wird in einem ersten Schritt definiert, hinsichtlich welcher Eigenschaften eine Funktion untersucht und bewertet werden soll. Im Anschluss werden Bewertungskriterien f\u00fcr diese Eigenschaften festgelegt und passende Wertebereiche definiert.<\/p>\n

      Exemplarisch wird in Kapitel 3.3 eine Evaluation des Rahmenwerks anhand von Funktionen aus dem Umfeld vernetzter Mobilit\u00e4t (Vehicle-to-Everything, V2X) skizziert.<\/p>\n

      3.1 Bewertungsschema f\u00fcr Funktionen<\/h3>\n

      Zur Definition der f\u00fcr die Qualit\u00e4tssicherung relevanten Eigenschaften einer Funktion kann das Software-Qualit\u00e4tsmodell der ISO 25010 herangezogen werden (vgl. Abb. 5 im\u00a0PDF<\/a>).<\/p>\n

      Angelehnt an diese 8 Qualit\u00e4tsattribute l\u00e4sst sich der Risikowert einer Funktion \u00fcber folgende Eigenschaften charakterisieren:<\/p>\n

        \n
      1. Funktionale Komplexit\u00e4t\u00a0(Functional Suitability)<\/em><\/li>\n
      2. Performanz-Relevanz\u00a0(Performance Efficiency)<\/em><\/li>\n
      3. Nutzbarkeits-Relevanz\u00a0(Usability)<\/em><\/li>\n
      4. Sicherheits-Relevanz\u00a0(Security, Reliability)<\/em><\/li>\n
      5. Interoperabilit\u00e4ts-Relevanz\u00a0(Compatibility, Portability)<\/em><\/li>\n<\/ol>\n

        F\u00fcr diese Eigenschaften gilt: Je h\u00f6her der jeweilige Risikowert, desto h\u00f6her ist das mit der Funktion assoziierte Risiko. Der methodische Ansatz ist also, Funktionen in diesen Eigenschaften unabh\u00e4ngig voneinander zu bewerten, um damit auf den Risikowert der Funktion als Ganzes R\u00fcckschl\u00fcsse ziehen zu k\u00f6nnen. Im Bereich der Qualit\u00e4tssicherung k\u00f6nnen die individuellen Bewertungen dazu genutzt werden, die entsprechenden Eigenschaften \u00fcber geeignete Testmethoden abzusichern und dabei gezielt Schwerpunkte zu setzen. So sind beispielsweise Ergonomie Tests nur dann notwendig, wenn auch eine Nutzbarkeits-Relevanz vorliegt.<\/p>\n

        3.2 Herleitung von spezifischen Risikofaktoren<\/h3>\n

        Um die in 3.1 eingef\u00fchrten Eigenschaften funktionsspezifisch bewerten zu k\u00f6nnen, m\u00fcssen Bewertungskriterien und ein Aggregationsschema definiert werden. F\u00fcr die Bewertungskriterien werden unter anderem die in Kapitel 2 eingef\u00fchrten Metriken herangezogen. Tabelle 1 veranschaulicht die Komposition anhand der wesentlichen Bewertungskriterien.<\/p>\n

        Die Bewertungsskalen der einzelnen Kriterien sind nach M\u00f6glichkeit bin\u00e4r gew\u00e4hlt; in Einzelf\u00e4llen werden kennzahlspezifische Skalen verwendet, die im Anschluss auf einen Wertebereich von 0 bis 1 normiert werden. Als Aggregationsschema wird das gewichtete arithmetische Mittel verwendet.<\/p>\n

        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
        \n

        Betrachtete funktionale Eigenschaft<\/em><\/strong><\/p>\n<\/td>\n

        		\n

        Bewertungskriterien<\/em><\/strong><\/p>\n<\/td>\n

        		\n

        Erl\u00e4uterung<\/em><\/strong><\/p>\n<\/td>\n<\/tr>\n

        \n

        Funktionale Komplexit\u00e4t<\/p>\n<\/td>\n

        		\n

        Anforderungs-Komplexit\u00e4t<\/p>\n<\/td>\n

        		\n

        Bewertung \u00fcber Satzbau von textuellen Anforderungen (vgl. 2.1)<\/p>\n<\/td>\n<\/tr>\n

        \n

        Anforderungsaufkommen<\/p>\n<\/td>\n

        		\n

        Anzahl an funktionalen Anforderungen an eine Fkt.<\/p>\n<\/td>\n<\/tr>\n

        \n

        Durchschnitt. SW-Komponenten Komplexit\u00e4t<\/p>\n<\/td>\n

        		\n

        Einbezug aller SW-Komponenten, die an Umsetzung der Funktion beteiligt sind<\/p>\n<\/td>\n<\/tr>\n

        \n

        Maximale SW-Komponenten Komplexit\u00e4t<\/p>\n<\/td>\n<\/tr>\n

        \n

        Performanz-Relevanz<\/p>\n<\/td>\n

        		\n

        Existenz Echtzeitanforderungen<\/p>\n<\/td>\n

        		\n

        Bin\u00e4re Bewertung (Ja\/Nein)<\/p>\n<\/td>\n<\/tr>\n

        \n

        Zeitkritisches Funktionsverhalten<\/p>\n<\/td>\n

        		\n

        Bin\u00e4re Bewertung (Ja\/Nein)<\/p>\n<\/td>\n<\/tr>\n

        \n

        Nutzbarkeits-Relevanz<\/p>\n<\/td>\n

        		\n

        Direkte Kundenschnittstelle<\/p>\n<\/td>\n

        		\n

        Bin\u00e4re Bewertung (Ja\/Nein)<\/p>\n<\/td>\n<\/tr>\n

        \n

        Sicherheits-Relevanz<\/p>\n<\/td>\n

        		\n

        ASIL Rating<\/p>\n<\/td>\n

        		\n

        Entsprechend ISO 26262<\/p>\n<\/td>\n<\/tr>\n

        \n

        Funktion Teil der V2X Kommunikation<\/p>\n<\/td>\n

        		\n

        Bin\u00e4re Bewertung (Ja\/Nein)<\/p>\n<\/td>\n<\/tr>\n

        \n

        Einsatz von Verschl\u00fcsselung<\/p>\n<\/td>\n

        		\n

        Notwendigkeit Verschl\u00fcsselung auf Ebene Kommunikationsprotokoll;
        \nBin\u00e4re Bewertung (Ja\/Nein)<\/p>\n<\/td>\n<\/tr>\n

        \n

        Interoperabilit\u00e4ts-Relevanz<\/p>\n<\/td>\n

        		\n

        Einsatz in verschiedenartigen Umgebungen<\/p>\n<\/td>\n

        		\n

        M\u00f6gliche Differenzierung: verschiedene Steuerger\u00e4te, verschiedene Fahrzeugarchitekturen, …<\/p>\n<\/td>\n<\/tr>\n

        \n

        Varianz in Schnittstellen<\/p>\n<\/td>\n

        		\n

        Bin\u00e4re Bewertung (Ja\/Nein)<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

        Tabelle 1: Exemplarische Bewertungskriterien f\u00fcr funktionale Eigenschaften<\/em><\/p>\n

        3.3 Evaluation anhand V2X Funktionen<\/h3>\n

        Zur Evaluation des Bewertungsschemas f\u00fcr den Risikowert einer Funktion werden exemplarisch die notwendigen Rahmenbedingungen f\u00fcr zwei V2X Funktionen definiert und die Ergebnisse in den jeweiligen Kriterien miteinander hinsichtlich Plausibilit\u00e4t verglichen. Eine inhaltliche Beschreibung der betrachteten Funktionen findet sich im Folgenden:<\/p>\n

        Funktion A: Firmware over the Air (FOTA)
        \n<\/em><\/strong>Um Software-Updates von Fahrzeug-Steuerger\u00e4ten ohne Werkstattbesuch zur erm\u00f6glichen, k\u00f6nnen ausgew\u00e4hlte Steuerger\u00e4te au\u00dferhalb des Betriebs \u00fcber ein Kommunikationsprotokoll nach geeigneter Authentifizierung durch den Kunden ferngesteuert aktualisiert werden.
        \nKernanforderungen an diese Funktion sind:<\/p>\n

          \n
        1. Robustheit gegen\u00fcber Unterbrechungen (z.B. Kommunikations- oder Stromausfall) und \u00e4u\u00dfere Manipulationseinfl\u00fcsse w\u00e4hrend des Flash-Vorgangs.<\/li>\n
        2. Pr\u00fcfung der zu aufzuspielenden Software auf Authentizit\u00e4t, bevor der Flash-Vorgang startet.<\/li>\n
        3. Verifikation eines erfolgreichen Flash-Vorgangs \u00fcber eine Pr\u00fcfsumme (oder vergleichbar) und Feedback an den Kunden. Bei fehlgeschlagenem Flash-Vorgang, M\u00f6glichkeit eines Rollbacks zur alten Software.<\/li>\n
        4. Kompatibilit\u00e4t des Flash-Vorgangs mit verschiedenartigen Steuerger\u00e4ten. Voraussetzung ist die Umsetzung eines einheitlichen Flash-Protokolls.<\/li>\n<\/ol>\n


          \nFunktion B: Cooperative Collision Avoidance (CoCA)<\/em><\/strong>
          \n<\/em>Zur verbesserten Kollisionsvermeidung k\u00f6nnen Fahrzeuge untereinander laterale und longitudinale Kontrollparameter \u00fcber einen Kommunikationsstandard, z.B. 5G Mobilfunk, austauschen und diese in Echtzeit auswerten. Es erfolgt eine Warnmeldung an den Fahrer und situationsabh\u00e4ngig ein Brems- oder Lenkeingriff, wenn Gefahrensituationen erkannt werden. Kernanforderungen an diese Funktion sind:<\/p>\n

            \n
          1. Fahrzeug-zu-Fahrzeug (V2V) Kommunikation in Echtzeit; unidirektionale Latenz von weniger als 10ms [3G16].<\/li>\n
          2. Robustheit gegen \u00e4u\u00dfere St\u00f6reinfl\u00fcsse inklusive Manipulation von Daten (umsetzbar beispielsweise \u00fcber verschl\u00fcsselte Kommunikation).<\/li>\n
          3. Eindeutige Identifizierung der Fahrzeuge gegeneinander.<\/li>\n
          4. 99,999%ige Zuverl\u00e4ssigkeit bei sicherheitsrelevanten Fahrman\u00f6vern [3G16].<\/li>\n<\/ol>\n

            In Tabelle 2 findet sich die Bewertung beider Funktionen anhand der definierten Bewertungskriterien.<\/p>\n

            \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
            \n

            Betrachtete funktionale Eigenschaft<\/em><\/strong><\/p>\n<\/td>\n

            		\n

            Bewertungskriterien<\/em><\/strong><\/p>\n<\/td>\n

            		\n

            Funktion A
            \nFOTA<\/em><\/strong><\/p>\n<\/td>\n

            		\n

            Funktion B
            \nCoCA<\/em><\/strong><\/p>\n<\/td>\n

            		\n

            Gew. Arithm. Mittel
            \nA\u00a0\u00a0\u00a0\u00a0\u00a0 B<\/em><\/strong><\/p>\n<\/td>\n<\/tr>\n

            \n

            Funktionale Komplexit\u00e4t<\/p>\n<\/td>\n

            		\n

            Anforderungs-Komplexit\u00e4t<\/p>\n<\/td>\n

            		\n

            0.5<\/p>\n<\/td>\n

            		\n

            0.6<\/p>\n<\/td>\n

            		\n

            0.58<\/p>\n<\/td>\n

            		\n

            0.75<\/p>\n<\/td>\n<\/tr>\n

            \n

            Anforderungsaufkommen<\/p>\n<\/td>\n

            		\n

            0.4<\/p>\n<\/td>\n

            		\n

            0.7<\/p>\n<\/td>\n<\/tr>\n

            \n

            Durchschnitt. SW-Komponenten Komplexit\u00e4t<\/p>\n<\/td>\n

            		\n

            0.6<\/p>\n<\/td>\n

            		\n

            0.8<\/p>\n<\/td>\n<\/tr>\n

            \n

            Maximale SW-Komponenten Komplexit\u00e4t<\/p>\n<\/td>\n

            		\n

            0.8<\/p>\n<\/td>\n

            		\n

            0.9<\/p>\n<\/td>\n<\/tr>\n

            \n

            Performanz-Relevanz<\/p>\n<\/td>\n

            		\n

            Existenz Echtzeitanforderungen<\/p>\n<\/td>\n

            		\n

            0<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n

            		\n

            0<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n<\/tr>\n

            \n

            Zeitkritisches Funktionsverhalten<\/p>\n<\/td>\n

            		\n

            0<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n<\/tr>\n

            \n

            Nutzbarkeits-Relevanz<\/p>\n<\/td>\n

            		\n

            Direkte Kundenschnittstelle<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n

            		\n

            0<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n

            		\n

            0<\/p>\n<\/td>\n<\/tr>\n

            \n

            Sicherheits-Relevanz<\/p>\n<\/td>\n

            		\n

            ASIL Rating<\/p>\n<\/td>\n

            		\n

            B<\/p>\n<\/td>\n

            		\n

            C<\/p>\n<\/td>\n

            		\n

            0.83<\/p>\n<\/td>\n

            		\n

            0.92<\/p>\n<\/td>\n<\/tr>\n

            \n

            Funktion Teil der V2X Kommunikation<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n<\/tr>\n

            \n

            Einsatz von Verschl\u00fcsselung<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n<\/tr>\n

            \n

            Interoperabilit\u00e4ts-Relevanz<\/p>\n<\/td>\n

            		\n

            Einsatz in verschiedenartigen Umgebungen<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n<\/tr>\n

            \n

            Varianz in Schnittstellen<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n

            		\n

            1<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

            Tabelle 2: Exemplarische Auswertung f\u00fcr V2X Funktionen<\/em><\/p>\n

            Bei Berechnung des Eigenschaften-\u00fcbergreifenden Risikowerts f\u00fcr die gesamte Funktion ergibt sich ein Wert von (0.58+0+1+0.83+1)\/5=0.68<\/em>\u00a0f\u00fcr Funktion A, und entsprechend\u00a0(0.75+1+0+0.92+1)\/5=0.73\u00a0<\/em>f\u00fcr Funktion B.<\/p>\n

            Es ist jedoch zumindest im Kontext der Qualit\u00e4tssicherung sinnvoller, die einzelnen Eigenschaften individuell zu betrachten. So ist aus den Bewertungen zum Beispiel ableitbar, dass Ergonomie Tests bei der Funktion\u00a0FOTA\u00a0<\/em>sinnvoll sind – auf Grund der notwendigen Authentifizierung durch den Kunden und anschlie\u00dfendem Feedback bei abgeschlossenem Flashvorgang -, bei der Funktion\u00a0CoCA<\/em>\u00a0allerdings im Umfang wesentlich eingeschr\u00e4nkt werden k\u00f6nnen. Des Weiteren ist aus den h\u00f6heren Werten der\u00a0CoCA<\/em>\u00a0Funktion bei Funktionaler Komplexit\u00e4t und Sicherheits-Relevanz ersichtlich, dass die Testintensit\u00e4t und damit der Testumfang f\u00fcr diese Funktion vergleichsweise h\u00f6her angesetzt werden muss.<\/p>\n

            4\u00a0 Zusammenfassung und Ausblick<\/h2>\n

            Im Rahmen dieses Beitrags wurde zun\u00e4chst der Bedarf f\u00fcr Metriken-getriebene Prozesse er\u00f6rtert und im Anschluss geeignete Qualit\u00e4tsschranken f\u00fcr die Anforderungs- und Architekturentwicklung definiert. Anschlie\u00dfend wurde ein Rahmenwerk zur Risikobewertung von Fahrzeugfunktionen vorgeschlagen, das die zuvor definierten Metriken aufgreift und in die Risikobewertung einbezieht. Somit wird eine h\u00f6here Aussagekraft erreicht und der Prozess der Risikobewertung anteilig objektiviert. Auf Basis der Risikowerte kann im Anschluss der Umfang und der Schwerpunkt der Qualit\u00e4tssicherungs-Ma\u00dfnahmen sinnvoll abgesch\u00e4tzt und gesteuert werden.<\/p>\n

            Die exemplarischen Ergebnisse sind vielversprechend und die hier skizzierte Methodik soll zuk\u00fcnftig weiter evaluiert werden. Dazu werden im Rahmen der Qualit\u00e4tssicherung unternehmensspezifische Risikogrenzschwellen definiert, die unmittelbaren Einfluss auf Testumfang und \u2013intensit\u00e4t haben.<\/p>\n

            Weiter ist geplant, Metriken aus sp\u00e4teren Software-Entwicklungsphasen, beispielsweise der Systemverifikation, in die Risikobewertung miteinzubeziehen und damit eine iterative Ann\u00e4herung w\u00e4hrend der Projektlaufzeit zu erm\u00f6glichen. Denkbare Einflussfaktoren sind beispielsweise funktionsspezifische Fehlerraten und die Stabilit\u00e4t der Anforderungen \u2013 gemessen \u00fcber eingehende \u00c4nderungsanfragen.<\/p>\n

            Bibliographie<\/h2>\n

            [SM07]\u00a0 Stallbaum, H.; Metzger, A.: Employing Requirements Metrics for Automating Early Risk Assessment. Proceedings of MeReP07, 2007.<\/p>\n

            [He10]\u00a0\u00a0 Heidenreich, M.: Metriken und Werkzeugunterst\u00fctzung zur \u00dcberpr\u00fcfung von Anforderungen. OBJEKTspektrum, Ausgabe RE, 2010<\/p>\n

            [No17]\u00a0\u00a0 Nowack, J. et. al.: Continuous Process for the Validation of Transmission Controls, CTI Symposium Shanghai,\u00a0To appear<\/em><\/p>\n

            [Ge08]\u00a0\u00a0 Geltinger, G. et. al.: Das SOPHIST Regelwerk, DHBW Ravensburg, 2008<\/p>\n

            [Ve17]\u00a0\u00a0 Venkitachalam, H. et. al.: Metric-based Evaluation of Powertrain Software Architecture, SAE Int. J. Passeng. Cars \u2013 Electron. Electr. System., S. 194-208, 2017<\/p>\n

            [PR12]\u00a0\u00a0 Veenendaal, Erik van: The PRISMA Approach, Uitgeverij Tutein Nolthenius, 2012<\/p>\n

            [Be99]\u00a0\u00a0 Benlarbi, S. et. al.: Issues in Validating Object-Oriented Metrics for Early Risk Prediction. Proceedings of 10th<\/sup>\u00a0ISSRE, International Symposium on Software Reliability Engineering, Flordia, USA, 1999<\/p>\n

            [No00]\u00a0\u00a0 Nogueira, J.C. et. al.\u00a0: A Formal Risk Assessment Model for Software Evolution. Proceedings of the 22nd ICSE, International Conference on Software Engineering, 2000<\/p>\n

            [Si11]\u00a0\u00a0\u00a0 Siller, A. et. al.: Systematisch zu Testf\u00e4llen \u2013 Anforderungsbasierte Strategie f\u00fcr Test und Absicherung von Elektrik\/Elektronik. Automotive 2011<\/p>\n

            [IS11]\u00a0\u00a0\u00a0 ISO\/IEC 25010:2011: System and software quality models,\u00a0https:\/\/www.iso.org\/iso<\/a>\u00a0[Oktober 2017]<\/p>\n

            [3G16]\u00a0\u00a0 3GPP TR 22.886 V15.0.0, Study on enhancement of 3GPP Support for 5G V2X Services, Release 15, 2016<\/p>\n

            Beitrag als PDF downloaden<\/strong><\/a><\/p>\n

            \n

            Software Engineering Management – unsere Trainings & Coachings<\/h2>\n

            Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n

            Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Software Engineering Management \/Prozess-, Projekt- und Produktmanagement.<\/p>\n

            Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n

            \n

            Software Engineering Management – Fachwissen<\/h2>\n

            Wertvolles Fachwissen zum Thema\u00a0Software Engineering Management \/Prozess-, Projekt- und Produktmanagement steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n

            Zu den Fachinformationen<\/strong><\/a><\/p>\n

            Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier<\/a>.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

            Ein Framework zur Risikobewertung von Fahrzeug-Funktionen Autoren: Christopher Kugler, Stefan Kowalewski, Lehrstuhl Informatik 11 \u2013 Embedded Software, RWTH Aachen University; German Baca Espinoza, Ralf Maquet, Jiju Vadakkepattath, Dirk Macke, Johannes Richenhagen,\u00a0FEV Europe GmbH Beitrag – Embedded Software Engineering Kongress 2017 Mobilit\u00e4t ver\u00e4ndert sich disruptiv: Neue Themenkomplexe wie Fahrzeugvernetzung und hochintelligente Assistenzsysteme stellen hohe Qualit\u00e4tsanforderungen an […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","inline_featured_image":false,"footnotes":""},"categories":[],"tags":[],"class_list":["post-7950","post","type-post","status-publish","format-standard","hentry"],"acf":[],"yoast_head":"\nMetriken-getriebene Prozessentwicklung im Rahmen zuk\u00fcnftiger vernetzter Mobilit\u00e4t - MicroConsult Academy GmbH<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.microconsult.de\/en\/metrics-driven-process-development-in-the-context-of-future-networked-mobility\/\" \/>\n<meta property=\"og:locale\" content=\"en_GB\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Metriken-getriebene Prozessentwicklung im Rahmen zuk\u00fcnftiger vernetzter Mobilit\u00e4t - MicroConsult Academy GmbH\" \/>\n<meta property=\"og:description\" content=\"Ein Framework zur Risikobewertung von Fahrzeug-Funktionen Autoren: Christopher Kugler, Stefan Kowalewski, Lehrstuhl Informatik 11 \u2013 Embedded Software, RWTH Aachen University; German Baca Espinoza, Ralf Maquet, Jiju Vadakkepattath, Dirk Macke, Johannes Richenhagen,\u00a0FEV Europe GmbH Beitrag – Embedded Software Engineering Kongress 2017 Mobilit\u00e4t ver\u00e4ndert sich disruptiv: Neue Themenkomplexe wie Fahrzeugvernetzung und hochintelligente Assistenzsysteme stellen hohe Qualit\u00e4tsanforderungen an […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.microconsult.de\/en\/metrics-driven-process-development-in-the-context-of-future-networked-mobility\/\" \/>\n<meta property=\"og:site_name\" content=\"MicroConsult Academy GmbH\" \/>\n<meta property=\"article:published_time\" content=\"2025-11-29T07:07:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-02-13T05:52:33+00:00\" \/>\n<meta name=\"author\" content=\"weissblau media\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"weissblau media\" \/>\n\t<meta name=\"twitter:label2\" content=\"Estimated reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"13 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\\\/\"},\"author\":{\"name\":\"weissblau media\",\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/#\\\/schema\\\/person\\\/b6d4c4ae959b068fbe8d9416ed019a0a\"},\"headline\":\"Metriken-getriebene Prozessentwicklung im Rahmen zuk\u00fcnftiger vernetzter Mobilit\u00e4t\",\"datePublished\":\"2025-11-29T07:07:00+00:00\",\"dateModified\":\"2026-02-13T05:52:33+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\\\/\"},\"wordCount\":2495,\"commentCount\":0,\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.microconsult.de\\\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\\\/\",\"url\":\"https:\\\/\\\/www.microconsult.de\\\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\\\/\",\"name\":\"Metriken-getriebene Prozessentwicklung im Rahmen zuk\u00fcnftiger vernetzter Mobilit\u00e4t - MicroConsult Academy GmbH\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/#website\"},\"datePublished\":\"2025-11-29T07:07:00+00:00\",\"dateModified\":\"2026-02-13T05:52:33+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/#\\\/schema\\\/person\\\/b6d4c4ae959b068fbe8d9416ed019a0a\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\\\/#breadcrumb\"},\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.microconsult.de\\\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.microconsult.de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Metriken-getriebene Prozessentwicklung im Rahmen zuk\u00fcnftiger vernetzter Mobilit\u00e4t\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/#website\",\"url\":\"https:\\\/\\\/www.microconsult.de\\\/\",\"name\":\"MicroConsult Academy GmbH\",\"description\":\"Professionelle Schulungen, Beratung und Projektunterst\u00fctzung\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.microconsult.de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-GB\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.microconsult.de\\\/#\\\/schema\\\/person\\\/b6d4c4ae959b068fbe8d9416ed019a0a\",\"name\":\"weissblau media\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/bbb409da4970da9446f6c49465d453cb8a0dae301e4d4f465b5c4e62408daa2e?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/bbb409da4970da9446f6c49465d453cb8a0dae301e4d4f465b5c4e62408daa2e?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/bbb409da4970da9446f6c49465d453cb8a0dae301e4d4f465b5c4e62408daa2e?s=96&d=mm&r=g\",\"caption\":\"weissblau media\"},\"sameAs\":[\"https:\\\/\\\/www.microconsult.de\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Metrics-driven process development in the context of future connected mobility - MicroConsult Academy GmbH","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.microconsult.de\/en\/metrics-driven-process-development-in-the-context-of-future-networked-mobility\/","og_locale":"en_GB","og_type":"article","og_title":"Metriken-getriebene Prozessentwicklung im Rahmen zuk\u00fcnftiger vernetzter Mobilit\u00e4t - MicroConsult Academy GmbH","og_description":"Ein Framework zur Risikobewertung von Fahrzeug-Funktionen Autoren: Christopher Kugler, Stefan Kowalewski, Lehrstuhl Informatik 11 \u2013 Embedded Software, RWTH Aachen University; German Baca Espinoza, Ralf Maquet, Jiju Vadakkepattath, Dirk Macke, Johannes Richenhagen,\u00a0FEV Europe GmbH Beitrag – Embedded Software Engineering Kongress 2017 Mobilit\u00e4t ver\u00e4ndert sich disruptiv: Neue Themenkomplexe wie Fahrzeugvernetzung und hochintelligente Assistenzsysteme stellen hohe Qualit\u00e4tsanforderungen an […]","og_url":"https:\/\/www.microconsult.de\/en\/metrics-driven-process-development-in-the-context-of-future-networked-mobility\/","og_site_name":"MicroConsult Academy GmbH","article_published_time":"2025-11-29T07:07:00+00:00","article_modified_time":"2026-02-13T05:52:33+00:00","author":"weissblau media","twitter_card":"summary_large_image","twitter_misc":{"Written by":"weissblau media","Estimated reading time":"13 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.microconsult.de\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/#article","isPartOf":{"@id":"https:\/\/www.microconsult.de\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/"},"author":{"name":"weissblau media","@id":"https:\/\/www.microconsult.de\/#\/schema\/person\/b6d4c4ae959b068fbe8d9416ed019a0a"},"headline":"Metriken-getriebene Prozessentwicklung im Rahmen zuk\u00fcnftiger vernetzter Mobilit\u00e4t","datePublished":"2025-11-29T07:07:00+00:00","dateModified":"2026-02-13T05:52:33+00:00","mainEntityOfPage":{"@id":"https:\/\/www.microconsult.de\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/"},"wordCount":2495,"commentCount":0,"inLanguage":"en-GB","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.microconsult.de\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.microconsult.de\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/","url":"https:\/\/www.microconsult.de\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/","name":"Metrics-driven process development in the context of future connected mobility - MicroConsult Academy GmbH","isPartOf":{"@id":"https:\/\/www.microconsult.de\/#website"},"datePublished":"2025-11-29T07:07:00+00:00","dateModified":"2026-02-13T05:52:33+00:00","author":{"@id":"https:\/\/www.microconsult.de\/#\/schema\/person\/b6d4c4ae959b068fbe8d9416ed019a0a"},"breadcrumb":{"@id":"https:\/\/www.microconsult.de\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/#breadcrumb"},"inLanguage":"en-GB","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.microconsult.de\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.microconsult.de\/metriken-getriebene-prozessentwicklung-im-rahmen-zukuenftiger-vernetzter-mobilitaet\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.microconsult.de\/"},{"@type":"ListItem","position":2,"name":"Metriken-getriebene Prozessentwicklung im Rahmen zuk\u00fcnftiger vernetzter Mobilit\u00e4t"}]},{"@type":"WebSite","@id":"https:\/\/www.microconsult.de\/#website","url":"https:\/\/www.microconsult.de\/","name":"MicroConsult Academy GmbH","description":"Professional training, consulting and project support","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.microconsult.de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-GB"},{"@type":"Person","@id":"https:\/\/www.microconsult.de\/#\/schema\/person\/b6d4c4ae959b068fbe8d9416ed019a0a","name":"weissblau media","image":{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/secure.gravatar.com\/avatar\/bbb409da4970da9446f6c49465d453cb8a0dae301e4d4f465b5c4e62408daa2e?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/bbb409da4970da9446f6c49465d453cb8a0dae301e4d4f465b5c4e62408daa2e?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/bbb409da4970da9446f6c49465d453cb8a0dae301e4d4f465b5c4e62408daa2e?s=96&d=mm&r=g","caption":"weissblau media"},"sameAs":["https:\/\/www.microconsult.de"]}]}},"post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/posts\/7950","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/comments?post=7950"}],"version-history":[{"count":7,"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/posts\/7950\/revisions"}],"predecessor-version":[{"id":11679,"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/posts\/7950\/revisions\/11679"}],"wp:attachment":[{"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/media?parent=7950"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/categories?post=7950"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.microconsult.de\/en\/wp-json\/wp\/v2\/tags?post=7950"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}