Gesamtsystem. Version: A-Muster

Transkript

1 -Systementwurf: Systemarchitektur- Gesamtsystem Version: A-Muster Projektbezeichnung Artio Projektleiter Herr Karlapp Verantwortlich Herr Deynet Systemarchitekt Erstellt am Zuletzt geändert :53 Bearbeitungszustand in Bearbeitung vorgelegt X fertig gestellt Dokumentablage Systemarchitektur.doc V-Modell-XT Version Version 1.2bw

2 Das V-Modell XT ist urheberrechtlich geschützt. Copyright 2006 V-Modell XT Autoren und andere. Alle Rechte vorbehalten. Das V-Modell XT ist unter der Apache License Version 2.0 freigegeben. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Zuletzt geändert: :53 2/18

3 Weitere Produktinformationen Mitwirkend [nicht beteiligt] HW-Architekt [nicht beteiligt] Logistikverantwortlicher [nicht beteiligt] SW-Architekt Erzeugung Produktumfang des Systems Gesamtsystemspezifikation (Pflichtenheft) [Dateiname] Änderungsverzeichnis Änderung Nr. Datum Version Geänderte Kapitel Beschreibung der Änderung Autor Zustand Alle Initiale Produkterstellung Deynet Dekomposition überarbeitet Deynet Dekomposition überarbeitet Deynet Abbildungen überarbeitet Deynet Alle Gesamtes Dokument überarbeitet Deynet Einleitung korrigiert Deynet Prüfverzeichnis Die folgende Tabelle zeigt einen Überblick über alle Prüfungen sowohl Eigenprüfungen wie auch Prüfungen durch eigenständige Qualitätssicherung des vorliegenden Dokumentes. Datum Geprüfte Version Anmerkungen Prüfer Neuer Produktzustand Review Deynet Review Deynet Review Deynet Zuletzt geändert: :53 3/18

4 Inhalt 1 Einleitung Architekturprinzipien und Entwurfsalternativen Dekomposition des Systems Dekomposition des Gesamtsystems Dekomposition der Teilsysteme Dekomposition der Segmente Querschnittliche Systemeigenschaften Übergreifender Datenkatalog Designabsicherung Zu spezifizierende Systemelemente Abbildungsverzeichnis Anhang Zuletzt geändert: :53 4/18

5 Zuletzt geändert: :53 5/18

6 1 Einleitung Ausgehend von den funktionalen und nicht-funktionalen Anforderungen an das System ist es Aufgabe des Systemarchitekten, eine geeignete Systemarchitektur zu entwerfen. Die Architekturprodukte dienen dabei sowohl als Leitfaden als auch zur Dokumentation der Entwurfsentscheidungen. In einem ersten Schritt werden richtungweisende Architekturprinzipien festgelegt und mögliche Entwurfsalternativen untersucht. Entsprechend der gewählten Entwurfsalternative wird die Zerlegung (Dekomposition) des Systems in Segmente, HW-, SWund Externe Einheiten beschrieben. Beziehungen und Schnittstellen zwischen den Elementen und zur Umgebung werden identifiziert und im Überblick dargestellt. Zusätzlich werden querschnittliche Systemeigenschaften wie Sicherheitskonzept, Transaktionskonzept oder Loggingkonzept festgelegt. Die gewählte Architektur wird hinsichtlich ihrer Eignung für das zu entwickelnde System bewertet. Offene Fragen können beispielsweise im Rahmen einer prototypischen Entwicklung geklärt werden. Hauptverantwortlicher für den Architekturentwurf ist der Systemarchitekt. Unterstützt wird er von verschiedenen Experten zu Einzelthemen wie HW-Entwicklung, SW- Entwicklung, Logistik, Systemsicherheit oder Ergonomie. Die Architektur stellt das zentrale Dokument für die Erstellung weiterer Produkte dar. Sie legt alle Segmente, HW-, SW- und Externe Einheiten des Systems fest. Entsprechend den Vorgaben werden für jede HW- oder SW-Einheit eine Architektur sowie für die jeweiligen Elemente die Spezifikationen erstellt. Zuletzt geändert: :53 6/18

7 2 Architekturprinzipien und Entwurfsalternativen Ziel dieser Entwicklung ist es, eine Freisprechanlage zu entwickeln, die modular aufgebaut ist. So ist es möglich, diese durch Austausch eines Moduls für unterschiedliche Mobiltelefonmodelle anzupassen. Mobiltelefonunabhängige Elemente müssen so nicht ausgetauscht werden. Bei dem zu entwickelnden System existiert eine fest montierte Halterung (Baseplate genannt) im Innenraum des Fahrzeugs. Auf diese wird das oben genannte austauschbare Modul (Cradle genannt) aufgesteckt. Dieses ist mobiltelefonspezifisch und besitzt somit für jedes Modell unterschiedliche Anschlüsse und Kontakte für das jeweilige Telefonmodell. Eine unter der Innenraumverkleidung des Fahrzeugs montierte Box (ECU genannt) realisiert die vom Mobiltelefon unabhängigen Funktionen der Freisprechanlage. Das Cradle dient als Vermittlungsschicht zwischen Mobiltelefon und ECU. Handyspezifische Anschlüsse und Protokolle werden durch das Cradle vereinheitlicht. Das heißt, eine Kommunikation findet nur zwischen Mobiltelefon Cradle und Cradle ECU statt. Die zuletzt genannte Kommunikation läuft über die Baseplate, die die Kommunikation durchschleift. Das heißt, eine aktive Kommunikation, also ein Umsetzen der Signale, findet hier nicht statt. Bei der Dekomposition des Systems gibt es zwei grundsätzliche Möglichkeiten: Entweder die je Schicht immer feinere Zerlegung des Gesamtsystems, oder das Sichtenkonzept. Hierbei repräsentiert jede Schicht eine eigenständige Sicht auf das Gesamtsystem. Die zuletzt genannte Möglichkeit ist für das zu entwickelnde System gut geeignet, da es den Aufbau besser widerspiegelt. Auf den höheren Ebenen befinden sich so Anschlüsse und Gehäuse der einzelnen Elemente. Die tieferen Ebenen enthalten die Innenleben der jeweiligen Elemente. Dies sind zum Beispiel die Elektronik und die darauf ablaufende Software. Zuletzt geändert: :53 7/18

8 3 Dekomposition des Systems In den folgenden Abschnitten werden die Dekomposition des Systems sowie die Schnittstellen zwischen den einzelnen Bestandteilen des Systems beschrieben. Hierbei werden die Schnittstellen zusätzlich in die folgenden Kategorien eingeteilt (vgl. Abbildung 1), die durch die Kürzel in den jeweiligen Klammern repräsentiert werden: Mechanische Schnittstelle (M): Es besteht eine mechanische Verbindung zwischen den beiden betroffenen Systemteilen unter einer mechanischen Verbindung versteht man zum Beispiel eine Schraubverbindung. Elektrisch analoge Schnittstelle (A): Die Schnittstelle fasst alle Spannungen zusammen, die einen beliebigen Wert innerhalb eines Bereiches annehmen können. Elektromechanische Schnittstelle (EM): Unter dieser Schnittstelle wird eine Verbindung angesehen, die sowohl elektrische als auch mechanische Eigenschaften gleichzeitig abbilden, z.b. Steckverbinder. Elektrisch digitale Schnittstelle (D): Unter einer elektrisch digitalen Schnittstelle versteht man ein elektrisches Signal, welches als digitaler Wert interpretiert wird, zum Beispiel ein Steuersignal für ein Relais oder eine CAN-Bus- Nachricht. Software-Schnittstelle (S): Unter einer Software-Schnittstelle versteht man eine Schnittstelle auf Software-Ebene, also zum Beispiel einen Funktionsaufruf einer anderen Software-Komponente. Abbildung 1: Vorhandene Schnittstellen Jede Ebene der nachfolgenden Dekomposition des Systems repräsentiert eine andere Sicht auf das Gesamtsystem. Die Schnittstellen auf jeweils einer Ebene repräsentieren ebenfalls eine eigenständige Sicht bzgl. der Kommunikation. 3.1 Dekomposition des Gesamtsystems Das Gesamtsystem wird in drei Teilsysteme zerlegt: Fahrzeug, Freisprechanlage und Telefon. Dabei ist die Freisprechanlage das zu entwickelnde System. In der folgenden Abbildung ist die Zerlegung des Gesamtsystems in Teilsysteme zu sehen. Zuletzt geändert: :53 8/18

9 Abbildung 2: Dekomposition des Gesamtsystems in Teilsysteme Beschreibung der Teilsysteme: Fahrzeug Das Fahrzeug ist ein externes System, das nicht zum Lieferumfang des Systems Freisprechanlage gehört. Freisprechanlage Die Freisprechanlage ist das zu erstellende System. Telefon Das Telefon ist ein externes System, das nicht zum Lieferumfang des Systems Freisprechanlage gehört. Beschreibung der Schnittstellen: FSA-Fahrzeug M: Die Schnittstelle ist dem Lastenheft zu entnehmen. Telefon-FSA M: Die Schnittstelle ist dem Konstruktionssatz zu entnehmen. 3.2 Dekomposition der Teilsysteme Die Freisprechanlage besitzt folgende Segmente: ECU, Baseplate, Cradle und Mikrofon. In Abbildung 3 ist die Zerlegung der Teilsysteme in Segmente zu sehen. Abbildung 3: Dekomposition der Teilsysteme in Segmente Beschreibung der Segmente: Baseplate Cradle Die Baseplate ist ein systemspezifisches elektrisches und mechanisches Bindeglied zum Cradle. Auf der Baseplate können Signalzustände durch LEDs angezeigt werden. Dies ist, bis auf weiteres, noch nicht näher festgelegt. Zuletzt geändert: :53 9/18

10 ECU Das Cradle stellt die Verbindung zum jeweiligen Telefon her. Für unterschiedliche Telefone existieren unterschiedliche Cradles. Das Cradle stellt dem System eine telefonunabhängige Schnittstelle zur Verfügung und realisiert den Freisprech- sowie ggf. den Datenmodus. Die Box steuert das Freisprechsystem und ist in der Lage sowohl mit dem Fahrzeug (über den CAN-Bus) sowie mit dem Cradle (über RS485) zu kommunizieren. In der Box werden die Audiosignale verarbeitet, also z.b. von Hintergrundgeräuschen befreit, sowie generell verstärkt. Zusätzlich stellt die Box dem Cradle die Versorgungsspannung zur Verfügung sowie die Spannung, die zum Laden des Telefons erforderlich ist. Eine weitere Funktion der Box ist die Diagnose des Freisprechsystems. Beschreibung der Schnittstellen: Cra-Bas EM: Die Schnittstellen der Baseplate sind dem Konstruktionssatz zu entnehmen. M: Die Schnittstellen der Baseplate sind dem Konstruktionssatz zu entnehmen. Cra-Tel E: Die Schnittstelle ist dem Konstruktionssatz zu entnehmen. M: Die Schnittstelle ist dem Konstruktionssatz zu entnehmen. Ecu-Bas EM: Die Schnittstellen der Baseplate sind dem Lastenheft zu entnehmen. Ecu-Mik EM: Die Schnittstelle ist dem Lastenheft zu entnehmen. Fah-Bas EM: Die Schnittstellen der Baseplate sind dem Lastenheft zu entnehmen. M: Die Schnittstellen der Baseplate sind dem Lastenheft zu entnehmen. Fah-Ecu EM: Die Schnittstelle ist dem Lastenheft zu entnehmen. M: Die Schnittstelle ist dem Lastenheft zu entnehmen. Fah-Mik M: Die Schnittstelle ist dem Lastenheft zu entnehmen. 3.3 Dekomposition der Segmente Das Segment Cradle besitzt folgende Einheiten: Cradle-SW und Cradle-Elektronik. Cradle-SW ist dabei eine SW-Einheit. Cradle-Elektronik ist eine HW-Einheit. Die Baseplate besitzt nur die HW-Einheit Baseplate-Elektronik. Die ECU besitzt die Einheiten ECU-SW und ECU-Elektronik. ECU-SW ist eine SW-Einheit, ECU-Elektronik eine HW-Einheit. In Abbildung 4 ist die Zerlegung der Segmente in Einheiten zu sehen. Zuletzt geändert: :53 10/18

11 Abbildung 4: Dekomposition der Segmente in Einheiten Beschreibung der Einheiten: Baseplate Elektronik In der Einheit Baseplate Elektronik sind die elektronischen Komponenten der Baseplate enthalten. Cradle Elektronik Die Einheit Cradle Elektronik umfasst die Elektronik des Cradle. Auf dieser Einheit läuft die SW-Einheit Cradle-SW. Außerdem umfasst sie die kommunikative Anbindung zu anderen HW-Einheiten. Cradle-SW Die Einheit Cradle-SW realisiert die Kommunikation mit dem Mobiltelefon. Mobiltelefonspezifische Protokolle und Datenflüsse werden vereinheitlicht und der Einheit ECU-SW so zur Verfügung gestellt. ECU Elektronik Die Einheit ECU Elektronik umfasst die Elektronik der ECU. Auf dieser Einheit läuft die SW-Einheit ECU-SW. Außerdem umfasst sie die kommunikative Anbindung zu anderen HW-Einheiten. ECU-SW Die SW-Einheit ECU-SW realisiert die eigentliche Funktionalität der Freisprecheinrichtung. CAN-Interface Über das CAN-Interface wird die Kommunikation mit dem Fahrzeug hergestellt. Beschreibung der Schnittstellen: BasEl-EcuEl D: Die Schnittstelle beschreibt die Anbindung der Baseplate Elektronik an die ECU Elektronik. CraEl-BasEl D: Die Schnittstelle beschreibt die Anbindung der Baseplate Elektronik an die Cradle Elektronik. CraEl-Tel Zuletzt geändert: :53 11/18

12 D: Die Schnittstelle beschreibt die Anbindung der Cradle Elektronik an das Mobiltelefon. Sie ist mobiltelefonspezifisch. CraSW-CraEl D/S: Die Schnittstellen zwischen Software und Elektronik sind durch die Systemspezifikation vorgegeben und werden durch Hardwarezugriffsfunktionen realisiert. CraSW-EcuSW S: CraSW und EcuSW kommunizieren miteinander, um handyspezifische Daten untereinander auszutauschen (zum Beispiel Telefonbucheinträge, Nachricht eines Anrufs,...) CraSW-Tel S: Die Schnittstelle zwischen Cradle-SW und Mobiltelefon sind durch die mobiltelefonspezifischen Protokolle vorgegeben. EcuEl-CAN D: Die Schnittstelle zwischen Ecu-Elektronik und CAN-Bus sind durch die Protokolle des Fahrzeugherstellers vorgegeben. Siehe hierzu Kapitel 5. EcuSW-EcuEl D/S: Die Schnittstellen zwischen Software und Elektronik sind durch die Systemspezifikation vorgegeben und werden durch Hardwarezugriffsfunktionen realisiert. EcuSW-CAN S: Die Schnittstelle wird zur Kommunikation mit dem CAN-Bus verwendet. Das Fahrzeug kann beispielsweise Anfragen an die Freisprechanlage (über CAN) senden oder Einstellungen vornehmen (zum Beispiel Lautstärkeregelung) Zuletzt geändert: :53 12/18

13 4 Querschnittliche Systemeigenschaften Das System stellt umfangreiche Diagnose-Funktionen zur Verfügung. Diese können über den CAN-Bus des Fahrzeugs abgefragt werden. Die Diagnose-Funktionen müssen in den SW-Einheiten berücksichtigt werden. Zuletzt geändert: :53 13/18

14 5 Übergreifender Datenkatalog Nur die Software wird in diesem System nach V-Modell entwickelt. Da es sich bei diesem Projekt um ein Pilotprojekt handelt, werden deshalb auch nur für die Einheit ECU-SW eine weiterführende Architektur inklusive Spezifikationen erstellt. Aus diesem Grund finden sich in diesem Thema auch nur die Schnittstellen CraSW-EcuSW und EcuSW-CAN wieder. Schnittstellen: CraSW-EcuSW Das Dokument Artio\Systemspezifikationen\SpezifikationCradle\COMMAND LAYER.doc beschreibt ausführlich die Kommunikation zwischen CraSW und E- cusw. EcuSW-CAN Das Dokument XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXX beschreibt die Kommunikation zwischen EcuSW und CAN-Bus hinsichtlich der Protokollschichten, den zeitlichen Randbedingungen und dem Datenfluss. In dem Dokument CommunicationXXXXXXXXXc werden die eigentlichen Datenpakete beschrieben. Zuletzt geändert: :53 14/18

15 6 Designabsicherung Die Entwicklung des Systems läuft iterativ ab. Dabei werden drei Iterationen durchlaufen (A-, B- und C-Muster). Die Architektur soll dabei durch die Prototypen des A- und B-Musters geprüft werden. Dabei ist darauf zu achten, dass alle vorhandenen Anforderungen umgesetzt wurden. Eventuell nicht erfasste Anforderungen sind dabei festzuhalten. Zuletzt geändert: :53 15/18

16 7 Zu spezifizierende Systemelemente Nur die Software wird in diesem System nach V-Modell entwickelt. Da es sich bei diesem Projekt um ein Pilotprojekt handelt, werden deshalb auch nur für die Einheit ECU-SW eine weiterführende Architektur inklusive Spezifikationen erstellt. EcuSW Zuletzt geändert: :53 16/18

17 8 Abbildungsverzeichnis Abbildung 1: Vorhandene Schnittstellen... 8 Abbildung 2: Dekomposition des Gesamtsystems in Teilsysteme... 9 Abbildung 3: Dekomposition der Teilsysteme in Segmente... 9 Abbildung 4: Dekomposition der Segmente in Einheiten Abbildung 5: Die Hardwareschnittstellen zwischen den einzelnen Segmenten Zuletzt geändert: :53 17/18

18 9 Anhang Abbildung 5: Die Hardwareschnittstellen zwischen den einzelnen Segmenten Zuletzt geändert: :53 18/18