Termin 10

Termin 10 - MCT-2
WiSe21/22
Stephan Schulze
07. Dezember 2021
Stephan Schulze (BHT Berlin / IAV GmbH) Termin 10 - MCT-2 07. Dezember 2021 1 / 22
Gliederung
1 (Serielle) Bussysteme
Grundlagen
CAN Bus
2 Entwicklungsprozess
Allgemein
V-Modell
Abschnitt 1
(Serielle) Bussysteme
Unterabschnitt 1
Grundlagen
(Serielle) Bussysteme
Grundlagen
Grundlegende Eigenschaften von Bus-Systemen:

Shared Medium (vgl. Ethernet)
Oftmals Master/Slave (Topologieabhängig)
Datenübertragung: Synchron ↔ Asynchron
Übertragungsfrequenzen: bis GBit/s
Teilnehmerbegrenzung
(Abschlusswiderstände)
...
Unterabschnitt 2
CAN Bus
CAN Bus
Grundlagen
Grundlegende Eigenschaften von CAN:

CAN = Controller Area Network
Ursprünglich entwickelt 1983 von Bosch zur Vernetzung von
Steuergeräten im Automobilbau.
Standardisierung ISO OSI Layer 1-2: ISO 11898
125 kBits/s (Low-Speed-CAN) - 1 MBits/s (High-Speed-CAN)
Max. ca. 100 Teilnehmer (Multi-Master, mit Kollisionsauflösung)
Botschaften mit 0-8 Datenbytes
CAN Bus
Topologie
Rterm = 200Ω (High-Speed-CAN vs. Low-Speed-CAN)

CAN-H, CAN-L
Abbildung 1: (High-Speed) CAN Topology [3]
CAN Bus
Elektrische Eigenschaften I
Auswertung der Potentialdifferenz: CAN-H - CAN-L

High-Speed-CAN vs. Low-Speed-CAN: PHY
High-Speed-CAN:
Logisch 0: ≈2V (”dominant”)
Logisch 1: 0V (”rezessiv”)
Aufgrund der Schaltung (”wired AND”) ist die Potentialdifferenz auf
der Leitung immer dann 0 (dominant), wenn mindestens ein
Teilnehmer eine 0 sendet.
CSMA/CR (→ Bit-Arbitrierung)
CAN Bus
Elektrische Eigenschaften II
0 1 0 1 1 0 1 1 0 0 0 1 1 0 1
5V
Dominant Voltage
CAN Hi
2.5V Recessive Voltage
CAN Lo
Dominant Voltage
0V
Driver Logic
Abbildung 2: (High-Speed) CAN (Electrical) [3]
1
0
Bits
1
CAN Bus
Start of frame
ID
CAN (Base)Frame
11
Message identifier
Remote transmission bit

Identifier extension bit 1 1 1
reserved
Stephan Schulze (BHT Berlin / IAV GmbH)

DLC
4
Data length code
Data field
0...64

Termin 10 - MCT-2
→ Was steckt hinter den einzelnen Feldern?
CRC
15
Abbildung 3: CAN Base-Frame [3]
Cyclic redundancy
checksum
CRC-Delimiter
ACK-Slot
1 1 1
ACK-Delimiter
7
End of frame
Inter frame space

07. Dezember 2021
11 / 22
Abschnitt 2
Entwicklungsprozess
Unterabschnitt 1
Allgemein
Entwicklungsprozess
Grundlagen
Entwicklungsprozesse sind die Grundlage für ein definierten Zustand im

Projekt, der SW-Entwicklung selbst und der Testbarkeit:
Beschreibt (auf ”High-Level”-Basis) die Methodik bzw.

Prozessabläufe, wie ein Produkt entwickelt wird.
Gängige Modelle im SW-Bereich:
V-Modell
Wasserfall-Modell
Agile (bspw. ”Scrum”)
TDD (”Test-Driven-Development”)
→ Prozesse spielen (auf für Entwickler) eine immer wichtigere Rolle.

Firmen werden bzgl. ihrer Prozesse auch Auditiert!
Unterabschnitt 2
V-Modell
Entwicklungsprozess
V-Modell I
Abbildung 4: V-Modell [?]
Entwicklungsprozess
V-Modell II
Das ”V” wird von links nach rechts durchlaufen

Jede Entwicklungsebene (links) besitzt ein Pendant auf der
Test-Ebene (rechts)
→ Die Idee hinter dem V-Modell: erst planen, dann entwickeln, dann
testen (das Gegenteil zu TDD bspw.).
Entwicklungsprozess
V-Modell III
1 LH / PH
Kunde sagt, was er haben will → Lastenheft (LH)
Auftragnehmer sagt, was er was er machen wird → Pflichtenheft (PH)
Sofern der Kunde das PH akzeptiert, sind das die bindenden
Kundenanforderungen
2 System-Requirements
Es werden abstrakte Requirements beschrieben, die das System
beschreiben (→ System-Architektur). Dies beinhaltet ”High-Level”
SW-, HW-, Konstruktion-Requirements.
3 Architektur
Hier wird die (in unserem Fall: SW-) Architektur beschrieben: Welche
Komponenten und Schnittstellen zwischen den Modulen gibt es und
was machen diese (nicht wie!).
Entwicklungsprozess
V-Modell IV
4 Feindesign / Component Design

Hier wird genau beschrieben wie eine SW-Komponente was umsetzt
(jedoch nicht in Form von Quellcode).
5 Komponenten-Erstellung (→ Implementierung)
Hier wird die eigentliche SW erstellt
Wichtig: Es darf keine SW-Anteile (sogar Codezeilen!) geben, die
nicht einem SW-Requirement zugeordnet werden können!
→ Auch eine CleanCode konvention: ”Implementiere nur das, was
gefordert ist”.
→ Jede Ebene besitzt ihren eigenen Abstraktions-Layer des Systems und

besitzt immer ein Pedant auf der Test-Ebene. So testet bspw. ein
allgemeiner ”SW-Test” nur das Gesamtverhalten der SW und nicht jeden
Algorithmus in jedem Modul.
Abschnitt 3
Anhang
Unterabschnitt 1
Quellen
Quellen I
Homepage von Herrn Prof. Dr. Gober

Linksammlung
https://prof.beuth-hochschule.de/gober/lehre/dokumentation-
mikrocontroller-stm32/
Unterlagen von Herrn Prof. Dr. Gober
Wikipedia [13.12.2020]
Wikipedia: CAN
https://en.wikipedia.org/wiki/CAN bus

Sprache

Termin 10

Hochgeladen von

Dokumentinformationen

Beschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Verfügbare Formate

Termin 10

Originaltitel:

Hochgeladen von

Beschreibung:

Copyright:

Verfügbare Formate

Termin 10 - MCT-2

07. Dezember 2021

Grundlegende Eigenschaften von Bus-Systemen:

Grundlegende Eigenschaften von CAN:

Rterm = 200Ω (High-Speed-CAN vs. Low-Speed-CAN)

Abbildung 1: (High-Speed) CAN Topology [3]

Auswertung der Potentialdifferenz: CAN-H - CAN-L

Abbildung 2: (High-Speed) CAN (Electrical) [3]

Remote transmission bit

Stephan Schulze (BHT Berlin / IAV GmbH)

Data length code

Abbildung 3: CAN Base-Frame [3]

Inter frame space

Entwicklungsprozesse sind die Grundlage für ein definierten Zustand im

Beschreibt (auf ”High-Level”-Basis) die Methodik bzw.

→ Prozesse spielen (auf für Entwickler) eine immer wichtigere Rolle.

Abbildung 4: V-Modell [?]

Das ”V” wird von links nach rechts durchlaufen

4 Feindesign / Component Design

→ Jede Ebene besitzt ihren eigenen Abstraktions-Layer des Systems und

Homepage von Herrn Prof. Dr. Gober

Verwandte Interessen

Das könnte Ihnen auch gefallen