84
Eingebettete Systeme (VAK 18.142) Prof. Dr.-Ing. D.P.F. Möller SS 2005 Technische Systeme Systeme Informatik Leitung: Prof. Dr.-Ing. D.P.F. Möller

Eingebettete Systeme (VAK 18.142) - uni-hamburg.de · 2.1 Grundstrukturen von HW-/SW-Systemen Prozessor Technologie Die Architektur des Prozessors wird dazu genutzt die Systemfunktionalität

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

Eingebettete Systeme (VAK 18.142)

Prof. Dr.-Ing. D.P.F. MöllerSS 2005

Tech

nisc

he

Syste

me

Syste

me

Info

rmat

ik

Leitung: Prof. Dr.-Ing. D.P.F. Möller

Embedded Systems (EBS)2. Architektur eingebetteter Systeme2.1 Grundstrukturen von Hardware-/Software-Systemen2.2 Implementierungstypen/Vorgehensweise bei der Modellierung2.2.1 Architekturmodell2.2.2 Reaktives Modell2.2.3 Funktionales Modell2.3 Entwurfsmethodiken und Modelle für den Entwurf eingebetteter

Systeme2.4 Beispiel: CCD Camera System

2.1 Grundstrukturen von HW-/SW-Systemen

2.1 Grundstrukturen von HW-/SW-SystemenEmbedded Systems Technologien

HW-Technologien für Embedded Systems basieren auf:

Prozessor TechnologieIC TechnologieDesign Technologie

2.1 Grundstrukturen von HW-/SW-SystemenProzessor Technologie

Die Architektur des Prozessors wird dazu genutzt die Systemfunktionalität zu implementieren Prozessor muss nicht programmierbar sein

“Prozessor” entspricht nicht GPP

Application-specific

Registers

CustomALU

DatapathController

Program memory

Assembly code for:

total = 0for i =1 to …

Control logic and State register

Datamemory

IR PC

Single-purpose (“hardware”)

DatapathController

Controllogic

State register

Datamemory

index

total

+

IR PC

Registerfile

GeneralALU

DatapathController

Program memory

Assembly code for:

total = 0for i =1 to …

Control logic and

State register

Datamemory

General-purpose (“software”)

2.1 Grundstrukturen von HW-/SW-SystemenProzessor Technologie

Prozessoren variieren im „Zuschnitt für das zu lösende Problem”

total = 0for i = 1 to N loop

total += M[i]end loop

General-purpose Prozessor

Single-purpose Prozessor

Anwendungs-spezifischer-

Prozessor

AngenommeneFunktionalität

2.1 Grundstrukturen von HW-/SW-SystemenGeneral-purpose Prozessoren

Programmierbare Einheiten die in vielfältigen Anwendungen eingesetzt werden könnenBekannt als “Mikroprozessor”, µP

FeaturesProgrammspeicherGeneralisierter Datenfluss mit großem Registerfile und “genereller” ALU

Nutzer VorteileTime-to-Market und NRE Kosten geringgroße Flexibilität

“Pentium” bekanntester GPP, jedoch gibt es an die 100 weitere GPPs

IR PC

Registerfile

GeneralALU

DatapathController

Program memory

Assembly code for:

total = 0for i =1 to …

Control logic and

State register

Datamemory

2.1 Grundstrukturen von HW-/SW-SystemenAnwendungs-spezifische Prozessoren

Programmierbarer Prozessor, optimiert für eine partikuläre Klasse von Anwendungen mit gleicher Charakteristik

Kompromiss zwischen GPP und SPPFeatures

ProgrammspeicherOptimierter DatenflussSpezielle Funktionseinheiten

VorteileGewisse Flexibilität, gute Performance, Größe und Versorgung

IR PC

Registers

CustomALU

DatapathController

Program memory

Assembly code for:

total = 0for i =1 to …

Control logic and

State register

Datamemory

2.1 Grundstrukturen von HW-/SW-SystemenSingle-purpose Prozessoren

Digitaler Schaltkreis, entworfen um ein einzelnes Programm auszuführen

Co-Prozessor, HW-Beschleuniger, periphere Komponente

FeaturesEnthält lediglich die Komponenten die zur Ausführung eines einzigen Programms erforderlich sindEnthält keinen Programmspeicher

VorteileschnellLow powerGeringe Abmaße

DatapathController

Control logic

State register

Datamemory

index

total

+

2.1 Grundstrukturen von HW-/SW-SystemenCustom single-purpose processor basic model

controller and datapath

controller datapath

externalcontrolinputs

externalcontrol outputs

externaldata

inputs

externaldata

outputs

datapathcontrolinputs

datapathcontroloutputs

… …

a view inside the controller and datapath

controller datapath

… …

stateregister

next-stateand

controllogic

registers

functionalunits

2.1 Grundstrukturen von HW-/SW-SystemenExample: Greatest Common Divisor (GCD)

GCD

(a) black-box view

x_i y_i

d_o

go_i

0: int x, y;1: while (1) {2: while (!go_i);3: x = x_i; 4: y = y_i;5: while (x != y) {6: if (x < y) 7: y = y - x;

else 8: x = x - y;

}9: d_o = x;

}

(b) desired functionality

y = y -x7: x = x - y8:

6-J:

x!=y

5: !(x!=y)

x<y !(x<y)

6:

5-J:

1:

1

!1

x = x_i3:

y = y_i4:

2:

2-J:

!go_i

!(!go_i)

d_o = x

1-J:

9:

(c) state diagramAbleitung des Algorithmus

Konvertierung Algorithmus in “komplexen” Zustands-automaten (state machine)

Bekannt als FSMD: finite-state machine mit Daten-flussKann Templates für performante Konver-tierung nutzen

2.1 Grundstrukturen von HW-/SW-Systemen

Kombinatorische LogikSequentielle LogikKundenspezischer single-purpose Prozessor Entwurf Kundenspezifischer single-purpose Prozessor Entwurf auf RT Ebene

2.1 Grundstrukturen von HW-/SW-SystemenErzeugung des Datenflusses

Erzeugung eines Registers für jede deklarierte Variable Erzeugung einer funktionellen Einheit für jede arithmetische OperationVerbinden der Ports, Register und Funktionseinheiten

Basierend auf reads und writesEinsatz von Multiplexern für mehrfache Quellen

Erzeugen unique identifierfür jede Datenpfad Komponente Überwachung der Ein- und Ausgänge

y = y -x7: x = x - y8:

6-J:

x!=y

5: !(x!=y)

x<y !(x<y)

6:

5-J:

1:

1

!1

x = x_i3:

y = y_i4:

2:

2-J:

!go_i

!(!go_i)

d_o = x

1-J:

9:

subtractor subtractor7: y-x8: x-y5: x!=y 6: x<y

x_i y_i

d_o

0: x 0: y

9: d

n-bit 2x1 n-bit 2x1x_sel

y_selx_ld

y_ld

x_neq_y

x_lt_yd_ld

<5: x!=y

!=

Datapath

2.1 Grundstrukturen von HW-/SW-SystemenOptimizing Single Purpose Processor

Optimierung bedeutet den Entwurfsprozess hinsichtlich der Entwurfsmetrik zum besten Ergebnis zu führenOptimierungsmöglichkeiten:

Original ProgrammFSMDDatenflussFSM

2.1 Grundstrukturen von HW-/SW-SystemenOptimizing the original program

Analyse der Programm Attribute und Erkennen von Verbesserungs-Möglichkeiten

Anzahl der Berechnungen Größe der VariablenZeit und Raum KomplexitätBenutzte Operationen

Multiplikation und Division sind sehr teuer

2.1 Grundstrukturen von HW-/SW-SystemenOptimizing the FSMD

Verbesserungen möglich durch:Zustands Kopplung

Zustände mit Konstanten auf Transitionen können eliminiert werden, Zustände mit unabhängigen Operationen können gekoppelt werden

Separate Zustände Zustände welche komplexe Operationen (a*b*c*d) erfordern können auf kleinere Zustände herunter gebrochen werden, was die HW Größe reduziert

Scheduling

2.1 Grundstrukturen von HW-/SW-SystemenOptimizing the datapath

Teilen von FunktionseinheitenEins-zu-Eins Übertragung, wie vorab dargestellt wurde, nicht erforderlich

Wenn Operationen in unterschiedlichen Zuständen auftreten, können sie sich eine einzelne Funktionseinheit teilen

Multi-funktionelle EinheitenALUs unterstützen eine Vielzahl von Operationen, sie können auf die unter-schiedlichen Zustände aufgeteilt werden

2.1 Grundstrukturen von HW-/SW-SystemenOptimizing the FSM

State encodingTask of assigning a unique bit pattern to each state in an FSMSize of state register and combinational logic varyCan be treated as an ordering problem

State minimizationTask of merging equivalent states into a single state

State equivalent if for all possible input combinations the two states generate the same outputs and transitions to the next same state

2.1 Grundstrukturen von HW-/SW-Systemen

Kunden spezifischer Single Purpose ProzessorZielorientierte Entwurfstechniken Werden entworfen um Algorithmen auszuführenTypischerweise wird auf FSMD aufgesetztCAD Tools sind von großem Nutzen

2.1 Grundstrukturen von HW-/SW-SystemenApplication Specific Processors (ASIP) in ES• ASIP: programmierbarer Prozessorkern für eine Klasse bestimmter

Anwendungen, die sich durch gleiche Charakteristiken darstellen lassen, z.B.: ~Embedded Control (EC)~DSP~Telekommunikation

µC und DSP sind zwei typische Vertreter für ASIPs• µC: µP der für EC Anwendungen optimiert wurde• DSP: µP der für digitale Signalverarbeitung optimiert wurde,

repräsentiert durch spezielle Tasks wie ~Signalfilterung~Transfomationend.h. rechenintensive mathematische Operationen

2.1 Grundstrukturen von HW-/SW-SystemenµC• Ein-Chip µP: typischerweise für ereignisgesteuerte Echtzeit-

Regelung technischer Prozessen eingesetzt. Häufig für EC eingesetzt die rauen Umwelteinflüssen ausgesetzt sind

• Repräsentiert Integration einer CPU mit Speicher und Peripherie auf einem Chip

• Vielzahl vom µC enthalten µP, der zuerst für General PurposeAnwendungen entwickelt und später mit Veränderungen im Embedded Bereich eingesetzt wurde.

2.1 Grundstrukturen von HW-/SW-SystemenBeispiele:

Motorola HC11 und 68K-Familie, deren Vorgänger der 6800 und der 68000 sind, Intel 8096, PIC (Mikrochip). Es gibt eine Reihe von Architekturen, die direkt für EmbeddedAnwendungen entwickelt wurden, zu ihnen zählen M-CoreTM, TriCoreTM, SH7000, 8051- und C166-Familie. Auf hohe I/O-Leistung, niedrigen Leistungsbedarf, hohe Codedichte und niedrige Produktionskosten optimiert.

2.1 Grundstrukturen von HW-/SW-Systemen

µC⇒ In den 80er Jahren wurden Ein-Chip-Computer in µC umgenannt,

die Produkte dahinter blieben teilweise die gleichen.⇒ Ende der 80er Jahre der Begriff EC. Damit wollte man sich gegen-

über den programmierbaren Systemen, wie dem PC abgrenzen.⇒ ES sind dediziert für eine Anwendung entworfen, so dass das ganze

Programm als ROM oder EPROM fester Bestandteil des Produktes ist und nicht vom Anwender verändert wird.

⇒ in den 90er Jahren wurde durch eine weitere Integration, der breiten Nachfrage nach 16 Bit Controllern und die zunehmende Vernetzung der Controller durch standardisierte Protokolle charakterisiert

2.1 Grundstrukturen von HW-/SW-SystemenFull-custom/VLSI

Alle Ebenen sind für partikuläre digitale Implementation als EmbeddedSystem optimiert

Placing transistorsSizing transistorsRouting wires

Vorteile:Exzellente Performance, geringe Abmessungen, low power

Nachteile:Hohe NRE Kosten (e.g., 300 T€), lange Zeit für time-to-market

2.1 Grundstrukturen von HW-/SW-SystemenSemi-custom

Untere Layer vollständig oder nur teilweise realisiert Entwickler muss “routing of wires” und teilweise “placing someblocks” selber vornehmen

Vorteile:Gute Performance, gute Abmessungen, geringe Größe, NRE Kosten geringer als bei Full-custom Implementation ($10k to $100k)

Nachteile:Entwicklung dauert Monate

2.1 Grundstrukturen von HW-/SW-SystemenPLD (Programmable Logic Device)

Alle Layer existierenDesigner kann IC verkaufen s canVerbindungen auf dem IC werden entweder erzeugt oder zerstört (Technologie) um die Funktionalität zu implementieren Field-Programmable Gate Array (FPGA) sind sehr populär

VorteileGeringe NRE Kosten, meistens IC Kern verfügbar

NachteileGrößer, teuer (30 € per unit), größere Versorgungsleistung, langsamer

2.1 Grundstrukturen von HW-/SW-SystemenMoore’s law

Wichtigster Trend bei IC für EBSVorhergesagt in 1965 vom Intel Co-Gründer Gordon Moore

IC transistor capacity has doubled roughly every 18 months for the past several decades

10,000

1,000

100

10

1

0.1

0.01

0.001

Logic transistors per chip

(in millions)

1981

198 3

198 5

198 7

198 9

199 1

199 3

199 5

199 7

199 9

200 1

200 3

200 5

200 7

200 9

Note: logarithmic scale

2.1 Grundstrukturen von HW-/SW-SystemenDesign productivity exponential increase

Exponentielles Wachstum während der letzten Dekaden

100,000

10,000

1,000

100

10

1

0.1

0.01

1983

1981

1987

1989

1991

1993

1985

1995

1997

1999

2001

2003

2005

2007

2009

Prod

uctiv

ity(K

) Tra

ns./S

taff

–M

o.

2.1 Grundstrukturen von HW-/SW-SystemenUnabhängigkeit von Prozessor und IC Technologie

Grundsätzliche Auswirkungen General vs. customHinsichtlich Prozessor Technologie oder IC TechnologieTechnologien sind unabhängig voneinander

General-purpose

processorASIP

Single-purpose

processor

Semi-customPLD Full-custom

General,providing improved:

Customized, providing improved:

Power efficiencyPerformance

SizeCost (high volume)

FlexibilityMaintainability

NRE costTime- to-prototype

Time-to-marketCost (low volume)

2.1 Grundstrukturen von HW-/SW-SystemenDesign Produktivitäts Lücke

Produktivität der Entwicklung überdurchschnittlich stark angestiegen währen der letzten Dekaden. Der Zuwachs an Verbesserung hält nicht Schritt mit dem Tempo der Chip Kapazität

10,000

1,000

100

10

1

0.1

0.01

0.001

Logic transistors per chip

(in millions)

100,000

10,000

1000

100

10

1

0.1

0.01

Productivity(K) Trans./Staff-Mo.

1981

198 3

198 5

198 7

198 9

199 1

199 3

199 5

199 7

199 9

200 1

200 3

200 5

200 7

200 9

IC capacity

productivity

Gap

2.1 Grundstrukturen von HW-/SW-SystemenDesign Produktivitäts Lücke

1981 leading edge chip erfordert 100 Design Monate10.000 Transistoren / 100 Transistoren/Monat

2002 leading edge chip erfordert 3.000 Design Monate15.000.000 Transistoren / 5000 Transistoren/Monat

2005 leading edge chip erfordert 30.000 Design Monate150.000.000 Transistoren / 5000 Transistoren/Monat

Design Kosten steigen von $1M auf $3.000M

10,0001,000

100101

0.1

0.010.001

Logic transistors per chip

(in millions)

100,00010,0001000100101

0.10.01

Productivity(K) Trans./Staff-Mo.

1981

198 3

198 5

198 7

198 9

199 1

199 3

199 5

199 7

199 9

200 1

200 3

200 5

200 7

200 9

IC capacity

productivity

Gap

2.1 Grundstrukturen von HW-/SW-SystemenThe mythical man-month

The situation is even worse than the productivity gap indicatesIn theory, adding designers to team reduces project completion timeIn reality, productivity per designer decreases due to complexities of team management and communication In the software community, known as “the mythical man-month” (Brooks 1975)At some point, can actually lengthen project completion time! (“Too many cooks”)

10 20 30 400

100002000030000400005000060000

43

24

1916 15 16

18

23

Team

Individual

Months until completion

Number of designers

1M transistors, 1 designer=5000 trans/monthEach additional designer reduces for 100 trans/monthSo 2 designers produce 4900 trans/month each

2.2 Implementierungstypen/Vorgehensweise bei derModellierung

Die Entwicklung hochkomplexer eingebetteter Systeme basiert auf der Lösung zweier fundamentaler Aufgaben:• Angemessenheit der Anforderungsspezifikation • Korrektheit der Realisierung des Endsystems.Beide Forderungen sind mit den heute gebräuchlichen Techniken des Hardware- bzw. Software-Entwurfs nicht optimal lösbar, weshalb dieMöglichkeiten zur Integration mathematisch-formaler Techniken für die Programm- und Systementwicklung sowie die Simulation zunehmend an Bedeutung gewinnen. Die Entwicklung eingebetteter Systeme ist dabei durch eine Reihe tech-nischer Anforderungen gekennzeichnet, die wesentlichen Einfluss auf die Auswahl der verwendeten Modellierungsmittel und die Form derAnwendung ausüben. Charakteristisch ist z.B. bei der Systemsteuerungbzw. der Systemregelung die starke Abhängigkeit vom Verhalten dertechnischen Geräte- bzw. Systemumgebung.

2.2 Implementierungstypen/Vorgehensweise bei derModellierung

Modellbildung und Simulation:• Systemverhaltens des eingebetteten Systems vor technischer

Installation um • frühzeitig Fehler zu eliminieren • Adäquatheit der Modellentscheidungen zu evaluieren.

• Brüche im Entwurfsprozess vermeiden ⇒ Modellbildung weitgehend aufbauend auf operationalen Ausdrucksmitteln

• Modellierung muss die für eingebettete Systeme relevanten Betriebs- bzw. Sicherheitsanforderungen gewährleisten.

In der Softwaretechnik werden komplexe Systeme durch Kombinationkomplementärer aber weniger komplexer Sichten modellieret. Durch systematischen Abgleich der verschiedenen Sichten können Fehlerkon-zeptionen und Inkonsistenzen der Modellierung zu einem frühenZeitpunkt erkannt werden.

2.2 Implementierungstypen/Vorgehensweise bei derModellierung

Bei der Systemmodellierung hochkomplexer eingebetteter Systeme hat es sich dabei als vorteilhaft erwiesen, ein Sichtenkonzept zu verfolgen:

Sichtenmodell der System-/Prozeßmodellierung⇓

Architekturmodell⇓

Reaktives Modell⇓

Funktionales Modell

2.2 Implementierungstypen/Vorgehensweise bei derModellierung

Architekturmodell:beschreibt Beziehungen zwischen den Klassen der eingesetzten Kompo-nenten und die konkrete Systemstruktur, wobei Klassen Objekte mit den selben Eigenschaften zusammenfassen; Objekt besteht aus Daten und Operationen (Methoden) zur Manipulation der DatenReaktives Modell:beschreibt zustandabhängige Interaktion mit anderen Komponenten und der Systemumgebung; wobei evtl. Zeitbedingungen einzuhalten sindFunktionales Modell:umfasst Datendefinitionen einer Komponente; Dateninvarianten und dieEin-/ Ausgabe-Relationen ihrer Operationen

2.2.1 Architekturmodell

• beschreibt Beziehungen zwischen den Klassen der eingesetzten Komponenten und die konkrete Systemstruktur,

• verwendet Objektorientierte Modellierungstechniken.System: Menge strukturierter Objekte, die miteinander interagierenund dabei ihren Zustand verändern. Beziehungen zwischen Objekten sind• Verbindung (association): hierbei findet eine Kommunikation

zwischen den Objekten statt, aber kein Besitz,• Ansammlung (aggregation): mehrere einfache Objekte werden zu

einem komplexen Objekt zusammengefasst,• Verallgemeinerung (generalization): hierbei wird eine neue Klasse

mit Hilfe anderer Klassen definiert.Beziehungen zwischen den Objektklassen wie z.B. Vererbung, werden mit Klassendiagrammen beschrieben

2.2.1 ArchitekturmodellBeispiel 1

2.2.1 ArchitekturmodellBeispiel 1

The increasing demands in water quality result in the need for more effective process control of wastewater treatment plants. One way increasing the efficiency is using a model-based on-line process control, which requires a suitable model that describes the dynamic behavior of the process good enough and is as simple as possible at the same time.Consider that the process of nitrification is the most important complex biochemical process in a wastewater treatment plant, consisting of several enzymatic reactions. The first step of the reaction, the oxidation of ammonia to nitrite, is performed by bacteria of the type nitrosomonas while the conversion of nitrite to nitrate is carried out by a bacteria of type nitrobacter. Both processes depend directly on each other since nitrite oxidation is a consecutive reaction to the ammonia oxidation and both reaction rates depend on the nitrite concentration.

Ref.: D.P.F.Möller, Mathematical and Computational Modeling and Simulation: Fundamentals and CaseStudies, Springer Publ. 2003

2.2.1 ArchitekturmodellBeispiel 1

2.2.1 ArchitekturmodellBeispiel 1

2.2.1 ArchitekturmodellBeispiel 1

2.2.1 ArchitekturmodellBeispiel 2

Dampfkesselsteuerung als Beispiel eines Architekturmodells:

Sensoren liefern aktuellen Wasserstand und DampfausstoßPumpen pumpen neues Wasser in den Kesseljede Pumpe ist mit Sensor versehen der Durchfluss von Wasser anzeigt->Pumpendefekte werden so erkanntAuslassventil für die Initialisierungsphase

2.2.1 ArchitekturmodellBeispiel 2

2.2.1 ArchitekturmodellBeispiel 2

Architekturmodell der eingebetteten Steuerung umfasst mehrere spezielle interne Modelle externer technischer Geräte:

Sensor Modell,Steam Sensor Modell,Water Sensor Modell,Water Output Model,Monitored Pump Modell,Pump Modell.

2.2.1 ArchitekturmodellBeispiel 2

Modelle enthalten Informationen über Sollwerte und Konstruktion der Geräte, um • durch Abgleich mit den tatsächlichen Werten mögliche Geräte-

defekte zu erkennen,• im Falle defekter Geräte, für eine gewisse Zeit arbeitsfähig zu

bleiben.Ikonen repräsentieren dabei:

Rauten: AggregationsbeziehungenDreiecke: SpezialisierungsbeziehungenSchwarzes Quadrat: wertbezogene (intern von der eingebetteten Steuerung verwendete) Modelle; Steuerung kann auf ihre Werte über die an den Aggregationsbeziehungen angegebenen Rollen-Rollennamen zugreifen

2.2.1 ArchitekturmodellBeispiel 2

Kommunikation mit externen Geräten über Unit Manager welcher Details des Übertragungsprotokolls umsetzt

Beispiel:2 Attribute (oberer und unterer Schätzwert eines Sensormodells)Operationen einzelnen KomponentenAufrufbeziehungen (durch gestrichelte Pfeile gekennzeichnet)

Zentrale (eingebettete) Steuerung nutzt Operationen der Geräte-steuerung zum öffnen und schließen der Pumpen

2.2.2 Reaktives Modell

Spezifikation des reaktiven Verhaltens

• verwendet bei eingebetteten Systemen Zustandsdiagramme mit denen die komplexen und zeitlichen Interaktionen nebenläufiger Systemkomponenten modelliert werden können

• beschreibt Kontrollflüsse mehrfach verschachtelter Unterbrechungsstrukturen strukturiert und anschaulich

• besitzt intuitive graphische Notation

2.2.2 Reaktives ModellBeispiel 1

Spezifikation des reaktiven Verhaltens

2.2.2 Reaktives ModellBeispiel 2

Beispiel: Reaktives Modell Dampfkesselsteuerung Oberste Ebene 2 Zustände: Steuerung arbeitet normal oder Nothalte-zustand

Events können ohne Einschränkungen Nothaltezustand auslösen; externes Stopsignal (STOP)von Gerätesteuerung erkannte fehlerhafte Übertragungen (Transmission_ Error)Fehlerhafte Kontrollsignale

Genauere Kenntnisse über reaktive Beziehungen liefert Zerlegung des normalen Betriebszustandes in Initialisierungszustand und aktiven Betriebszustand. Initialisierungszustand = Dampfkessel nicht aufgeheizt, daher führt Anzeige Dampfaustritt nach Übertragung neuer Dampf-werte (Aufruf der Operation STEAM) zur Notabschaltung

2.2.2 Reaktives ModellBeispiel 2

2.2.2 Reaktives ModellBeispiel 2

Auslösebedingungen von Transitionen in eckigen Klammern notiert. Definition verwendeter Bedingungen, z.B. not V.Zero, erfolgt im funktionalen ModellAbbruchgründe sind in bestimmten Initialisierungsphasen auftretende Auszeiten und beliebige GeräteausfälleNach Abschluss des Initialisierungsprotokolls

PHYSICAL_UNITS_READY geht eingebettete Steuerung in aktiven Betriebszustand überModellierung durch weitere Zerlegung des Initialisierungszustands.Im aktiven Betriebszustand führen zwei Gründe zum Abschalten:1. zu hoher Wasserstand (LEVEL[Q.Dangerous])2. gleichzeitiges Ausfallen mehrerer Geräte (unit failures during

operation)Betriebsmodus wird periodisch an Gerätesteuerung (UnitManager)übertragen

2.2.3 Funktionales Modell

Spezifikation des funktionalen Verhaltensverwendet beim Modellierungsprozess eingebetteter Systeme mathematische Konstrukte wie z.B. • Z-Notation• Beschreibung von Zustandsräumen• komplexe Transformationen auf Zustände• etc.Spezifiziert komplexe Datenbeziehungen (lokale Datenstruk-

turen und Datentransformationen) des Systems.

2.2.3 Funktionales ModellBeispiel 1

Spezifikation des funktionalen Verhaltens

−−+−+ →+++→+ 3222224 5.025.1 NOONOHOHNOONH

rcVFc

VF

dtdc

±⋅−⋅= 22

112

2.2.3 Funktionales ModellBeispiel 2

Spezifikation des funktionalen Verhaltens

Funktionales Modell im Zustandsraum (state chart) beinhaltet2 Teile: Signaturteil, in dem Variablen verschiedenen Typs entweder explizit oder über die Inklusion anderer Schemata deklariert werdenPrädikatteil, in dem logische Beziehungen zwischen den im Signaturteil deklarierten Variablen beschrieben werden

2.2.3 Funktionales ModellBeispiel 2

Beispiel:Spezifikation funktionales Modell Operation Aktualisierung Wasserstand4/21. Hilfskalkulation2. Spezifikation Gesamtoperation; überprüfen ob aktuell übertragene

Werte innerhalb eines Schätzintervalls liegen. Ist dies nicht der Fall wird von Ausfall des Wasserstandsmelders ausgegangen. Dabei wird im funktionalen Modell der aktuelle Wasserstand als Eingabe-parameter zu der im reaktiven Model verwendeten Operation LEVEL definiert

2.3 Implementierungstypen2.3.1 Konsistenz zwischen Modellen

Validierung der Konsistenzmittels Abbildung zwischen den in den Modellen verwendeten Symbolen/Parametern anhand der Konsistenzforderungen

relativ einfache strukturelle Bedingungenkomplexe verhaltensbezogene Eigenschaften

2.3 Implementierungstypen2.3.1 Konsistenz zwischen ModellenBeispiel 1

2.3 Implementierungstypen2.3.1 Konsistenz zwischen ModellenBeispiel 2

Verwendung gleicher Namen: Level: fehlende Teile werden definiert, z.B. zu Unterzuständen –INITIA-LIZING, RUNNIG-; im funktionalen Modell werden korrespondierende Schemata definiert. Definitionen erfüllen weiteren Zweck: präzise Beschreibung der Schran-ken der Unterzustände die interne Gerätemodelle einhalten müssen und welche Geräteausfälle toleriert Werden können, d.h. Präzisierung der Verfügbarkeits- und Sicherheitsanforderungen.Ist Assoziation zwischen den Gegenständen der verschiedenen Modelle festgelegt, lassen sich systematisch Bedingungen identifizieren, deren Nachweis die Konsistenz zwischen reaktiven und funktionalen Modell validiert. Neben strukturellen Bedingungen auch verhaltensbezogene Bedingungen zur Konsistenz von Überlappungen zwischen den Model-len, die sich mit der konsistenten Verwendung von Zustanden und Operationen im reaktiven und funktionalen Modell beschäftigen

2.4 Beispiel: CCD Camera System

CCD KameraEntwurfsgesichtspunkte Spezifikation der AnforderungenEntwurf

Möglichkeiten zur Implementation

Möglichkeiten zur ImplementationGPP (General-Purpose Prozessor)SPP (Single-Purpose Prozessor)

CustomizedStandard

SpeicherInterface

Wissen vorhanden um CCD Kamerasystem entwickeln zu könnenGPP vs. SPP Partitionierung der Funktionalität über verschiedene Prozessor-typen

2.4 Beispiel: CCD Camera System Einleitung

2.4 Beispiel: CCD Camera System Einleitung

Bildaufnahmespeichert Bilder im Digitalformat

Kein FilmViele Bilder speicherbar

Anzahl abhängig vom Speicher und den Bits pro BildBilder auf PC übertragbarseit kurzem möglich:

Systems-on-a-Chip (SoC)Mehrere Prozessoren und Speicher in einem IC

High-Capacity Flash MemoryBeispiel basiert auf einfacher Beschreibung

viel mehr Möglichkeiten bei realer Digitalkamera als im Beispiel variable Bildgröße, Bildlöschung, Bilddehnung, Zoom in und out, etc.

2.4 Beispiel: CCD Camera System Entwicklungsperspektiven

Spezifische FunktionenBildverarbeitung und Speicherung

Wenn shutter gedrückt:BildaufnahmeKonvertierung in digitales Format durch Charge-CoupledDevice (CCD)Komprimierung zwecks Archivierung im internen Speicher

Bildübertragung auf den PCDigitalkamera wird mit PC verbundenSerielle Bildübertagung der archivierten Bilder durch spezielle Software

2.4 Beispiel: CCD Camera System Charge-coupled device (CCD)

Spezieller Sensor für BildaufnahmeLichtsensitive Halbleiterkomponente aus Silizium, bestehend aus vielen Zellen

When exposed to light, each cell becomes electrically charged. This charge can then be converted to a 8-bit value where 0 represents no exposure while 255 represents very intense exposure of that cell to light.

Some of the columns are covered with a black strip of paint. The light-intensity of these pixels is used for zero-bias adjustments of all the cells.

The electromechanical shutter is activated to expose the cells to light for a brief moment.

The electronic circuitry, when commanded, discharges the cells, activates the electromechanical shutter, and then reads the 8-bit charge value of each cell. These values can be clocked out of the CCD by external logic through a standard parallel bus interface.

Lens area

Pixel columns

Covered columns

Electronic circuitry

Electro-mechanical

shutter

Pixe

l row

s

2.4 Beispiel: CCD Camera System Zero-Bias Fehler

Herstellungsbedingte Fehler bewirken das die Zellenwerte leicht über oder unter der tatsächlichen Helligkeit liegen,Fehler der Spaltensignale typischerweise gleich, in Zeilen dagegen unterschiedlich Einige der linken Spalten sind geschwärzt um Null-Fehler festzulegen

wird ein von Null verschiedener Wert im geschwärzten Bereich gelesen, liegt ein Zero-Bias Fehler vorjede Zeile wird durch Subtraktion des Mittelwertfehlers korrigiert, der aus den geschwärzten Teilen resultiert

123 157 142 127 131 102 99 235134 135 157 112 109 106 108 136135 144 159 108 112 118 109 126176 183 161 111 186 130 132 133137 149 154 126 185 146 131 132121 130 127 146 205 150 130 126117 151 160 181 250 161 134 125168 170 171 178 183 179 112 124

136 170 155 140 144 115 112 248 12 14145 146 168 123 120 117 119 147 12 10144 153 168 117 121 127 118 135 9 9176 183 161 111 186 130 132 133 0 0144 156 161 133 192 153 138 139 7 7122 131 128 147 206 151 131 127 2 0121 155 164 185 254 165 138 129 4 4173 175 176 183 188 184 117 129 5 5

Covered cells

Before zero-bias adjustment After zero-bias adjustment

-13-11-90-7-1-4-5

Zero-bias adjustment

2.4 Beispiel: CCD Camera System Kompression

Mehr Bilder speichernBildübertragung an den PC in kürzerer ZeitJPEG (Joint Photographic Experts Group) Format

Standard Format zur Darstellung digitaler Bilder in komprimierter Formermöglicht unterschiedliche BetriebsmodiBeispielmodus (Beispiel 3) soll hohe Kompressionsrate erzeugen durch DCT (Discrete Cosine Transform)Bilddaten in Blöcke von 8 x 8 Pixel aufgeteilt3 Funktionen werden in jedem Block ausgeführt:

DCTQuantisierungHuffman encoding

2.4 Beispiel: CCD Camera System DCT

Transformiert 8 x 8 Blöcke in (Cosinus) den Frequenzbereichoberer linker Eckwert repräsentiert den Inhalt des Gesamtbildesunterer rechter Eckwert repräsentiert feinere Details

Genauigkeit der Eckwerte kann verringert werden um annehmbare Bildqualität zu erreichen

FDCT (Forward DCT:Discrete Cosine Transform) FormelC(h) = if (h = 0) then 1/sqrt(2) else 1.0

Hilfsfunktion zur Substitution in der Hauptfunktion F(u,v)F(u,v) = ¼ x C(u) x C(v) Σx=0..7 Σy=0..7 Dxy x cos(π(2u + 1)u/16) x cos(π(2y + 1)v/16)

ergibt verschlüsselte Pixel in Zeile u, Spalte vDxy repräsentiert ursprünglichen Pixelwert in Zeile x, Spalte y

IDCT (Inverse DCT_Discrete Cosine Transform)Gegenteiliges Vorgehen im Original Block (in Beispiel 3 nicht angewandt)

Erzeugen von Serien von 8 x 8 Pixel Blöcken Konvertierung der Werte in eine Liste basierend auf einem Zickzack Muster

Ausführen der Huffman KodierungHäufig benutzte Pixel werden durch kurzen Code repräsentiertLange binäre Codes repräsentieren weniger oft benutzte Pixel

Jedes Pixel in der Liste wird in Huffman verschlüsselte Werte gewandelt

Kürzere Liste ⇒ Kompression

2.4 Beispiel: CCD Camera System Huffman encoding

2.4 Beispiel: CCD Camera System Huffman encoding example

Pixel Frequenz linksPixel Wert –1 Häufigkeit 15 Pixel Wert 14 Häufigkeit 1 mal

Huffman BAUM bottom upEin Blatt Knoten für jeden Pixel Wert, Zuordnung der Frequenzals Knoten WertErzeugen interner Knoten fürjeden zweiten Knoten dessenSumme minimal ist

Summe ist interner KnotenWert v

Wiederholen bis binärer Baum vervollständigt ist

Binärcode der Blätterpixelindem Baum von der Wurzel zuden Blätterm durchlaufen wird

Egibt 0 für linken Durchlauf, 1 für rechten Durchlauf

Huffman Encoding reversibelKein Code ist Voraussetzungfür anderen Code

144

5 3 2

1 0 -2

-1

-10 -5 -3

-4 -8 -96141 1

2

1 1

2

1

22

4

3

5

4

65

9

5

10

5

115

14

6

17

8

1815

29

35

64

1

-1 15x 0 8x-2 6x1 5x2 5x3 5x5 5x-3 4x-5 3x

-10 2x144 1x-9 1x-8 1x-4 1x6 1x

14 1x

-1 000 100-2 1101 0102 11103 10105 0110-3 11110-5 10110

-10 01110144 111111-9 111110-8 101111-4 1011106 011111

14 011110

Pixel Frequenz

Huffman Baum Huffman Code

2.4 Beispiel: CCD Camera System Datenübertragung zum PC

Bei Verbindung mit PC wird upload Kommando ausgesandtLesen der Bilder vom SpeicherSerielle Übertragung über UARTWährend Bildübertragung

Rückstellen der Zeiger, Bildgröße, Variablen und global Speicherzeiger

2.4 Beispiel: CCD Camera System Funktionsunabhängige Anforderungen

Performancemuss Bild so schnell wie möglich verarbeiten 1 sec als Zielvorgabe

weniger ist schlechter schneller nicht erforderlich für low-end Bereich des Marktes

⇒ Constrained MetrikSize

muss EBS-IC verwenden der in Kameraabmessungen passt⇒ Constrained und optimierte Metrik

Constraint können 200,000 Gatter sein, aber weniger wäre billiger

Powermuss bei unterschiedlichen Temperaturen arbeiten (Lüfter nicht möglich)⇒ Constrained Metrik

EnergyStromaufnahme verringern, sonst Betriebszeit eingeschränkt⇒ optimierte Metrik: Batterienutzung solange wie möglich

2.4 Beispiel: CCD Camera System Entwurf

Festlegung der SystemarchitekturProzessoren

Jede Kombination von SPP (custom or standard) oder GPPSpeicher, Busse

Funktionalität auf Architektur übertragen Vielfältige Funktionen in einem ProzessorEine Funktion in einem oder mehreren Prozessoren

ImplementationPartikuläre Architektur und deren ÜbertragbarkeitBasissatz von Funktionen für alle Implementierungen

Beginn:Low-end GPP verbunden mit flash memory

Funktionaltät in SW übertragen die auf Prozesor abläuftBefriedigt Anforderung an Stromverbrauch, Größe, Time-to-Market constraintsBei unzureichenden timing constraint verspätete Implementation

IC Kosten inklusive NRE liegen bei $5Einsatz SPP für zeitkritische Funktionen Neufestlegung der funktionalen Spezifikation

2.4 Beispiel: CCD Camera System Implementation 1: Microcontroller

Low-end Prozessor, z.B. Intel 8051 MicrocontrollerUnter 200 mW Time-to-market in rund 3 MonatenNB, 1 Bild pro Sekunde nicht möglich

12 MHz, 12 Zyklen per Instruktion1 Million Instruktionen per Sekunde

CcdppCapture hat ineinandergreifende Schleifen resultiert in 4096 (64 x 64) Iterationen

~100 Assembler Instruktionen bei jeder Iteration 409,000 (4096 x 100) Instruktionen per BildHälfte des Budgets erforderlich allein um Bild auszulesen

Liegt über Budget wenn rechenzeitintensive DCT und Huffman Verschlüsselungsverfahren eingesetzt werden

2.4 Beispiel: CCD Camera System Implementation 2: Microcontroller und CCDPP

CCDPP Funktion in custom SSP implementiertverbesserte Performance – weniger Microcontroller Zyklenerhöhte NRE Kosten und Time-to-Marketeinfache Implementierung

einfacher Datenflusswenige Zustände im Embedded Controller

einfacher UART, einfache Implementierung als SPPEEPROM für Programmspeicher und RAM für Datenspeicher

8051

UART CCDPP

RAMEEPROM

SOC

2.4 Beispiel: CCD Camera System Microcontroller

Synthetisierbare Version des Intel 8051 verfügbar

geschrieben in VHDL umgesetzt auf Register Transfer Level (RTL)

Holt Instruktion vom ROMDecodierung basiert auf InstruktionsDecoderALU führt arithmetische Operationen aus

Quellen und Zielregister im RAM

Datenverschiebungsinstruktionen für externes Laden und SpeichernSpezielle Programme erzeugen VHDL Beschreibung des ROM vom Ausgang des C compiler/linker

To External Memory Bus

Controller

4K ROM

128RAM

Instruction Decoder

ALU

Block diagram of Intel 8051 processor core

2.4 Beispiel: CCD Camera System UART

UART im Idle Modus wenn nicht aktivUART aktiviert wenn 8051 gespeicherte Instruktionen mit UART enable Register als Zieladresse ausführt

Memory-mapped Kommunikation zwischen 8051 und allen SPPsuntere 8-Bit der Speicheradressen fürRAMobere 8-Bit der Speicheradressen für memory-mapped I/O devices

Startzustand überträgt 0 zur Anzeige des Beginns der Byte Übertragung, danach erfolgt Übertragung des DatenzustandsDatenzustand überträgt seriell 8 Bit, danach erfolgt Übertragung des StopzustandsStopzustand überträgt 1 zur Anzeige das die Übertragung erfolgt ist, danach Rückkehr in den Idle Modus

invoked

I = 8

I < 8

Idle:I = 0

Start: Transmit

LOW

Data: Transmit data(I),

then I++

Stop: Transmit

HIGH

FSMD description of UART

2.4 Beispiel: CCD Camera System Analyse

SOC Test auf VHDL simulatorInterpretiert VHDL Beschreibungund Funktionalität, Simulation Systemausführung

Recall Program Code wird in VHDL Beschreibung ins ROM übertragen

Test auf korrekte FunktionalitätMisst clock Zyklen für Bildverar-beitung (performance)

Gate-level Beschreibung als Syn-these-Ergebnis

Synthese Tool wie Compiler SPSSimuliert gate-level Modelle um Daten für die Leistungsanalyse zuerhalten

Number of times gates switch from 1 to 0 or 0 to 1

Zählt Nummer der Gatter für Chip Fläche

Power

VHDL simulator

VHDL VHDL VHDL

Execution time

Synthesis tool

gates gates gates

Sum gates

Gate level simulator

Power equation

Chip area

Obtaining design metrics of interest

2.4 Beispiel: CCD Camera System VHDL

Geometrie

StrukturVerhaltenSystemebene

Algorithmische Ebene

Register-Transfer-Ebene

Logikebene

Schaltkreisebene

Masken, Polygone

Zellen

Floorplan

Cluster

Partitionierung

Module, Leitungen

Transistoren, Leitungsstücke

Gatter, Flip-Flops, Leitungen

Subsysteme, Busse

CPUs, Speicher

Boolsche Gleichungen

Register-Transfers

Differentialgleichungen

SystemspezifikationAlgorithmen

D.P.F.Möller:Rechnerstrukturen, Kap. 7, Springer Verlag, ISBN 3-540-67838-4

2.4 Beispiel: CCD Camera System VHDL

Entity

Architecture

Configuration

Package

Schnittstellenbeschreibung (Parameter, I/O-Signale)

Verhaltens- oder Strukturale Beschreibung

Parametrisierung des Designs, Auswahl der Architektur und von Submodulen

'Include' für Typen, oft benötigte Funktionen, Konstanten, Komponenten

D.P.F.Möller:Rechnerstrukturen, Kap. 7, Springer Verlag, ISBN 3-540-67838-4

2.4 Beispiel: CCD Camera System VHDL

Modell

Verhaltens-

Schnittstelle nach außen

beschreibungKombinierteBeschreibung

StrukturaleBeschreibung

Eine Entity pro Modell

Mehrere Architekturen mitverschiedenen Entwurfssi

Konfiguration 1 Konfiguration 2Default Mehrere Konfigurationen, auch Default möglich

D.P.F.Möller:Rechnerstrukturen, Kap. 7, Springer Verlag, ISBN 3-540-67838-4