This commit is contained in:
David Schirrmeister 2024-06-27 11:44:33 +02:00
parent 7d50aa203d
commit dc5850cc01
33 changed files with 275 additions and 4 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 43 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 43 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 88 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 88 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 69 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

View File

@ -55,7 +55,9 @@
<toc-element topic="Klassifikation.md"/>
<toc-element topic="arm.md">
<toc-element topic="arm_toolchain.md"/>
<toc-element topic="arm_befehle.md"/>
<toc-element topic="arm_befehle.md">
<toc-element topic="arm_adressierung.md"/>
</toc-element>
</toc-element>
</toc-element>
<toc-element toc-title="EWI">

View File

@ -200,4 +200,138 @@
- Was innerhalb der Blackbox passiert spielt keine Rolle
### Übung Little's Law
![image_396.png](image_396.png)
![image_396.png](image_396.png)
## Prozesssimulation
### Definition
- Nachbildung der Ist-/Soll-Realität
- zum Optimieren
- dynamisch experimentieren
### Nutzenpotential
- Betriebsabläufe ohne Unterbrechungen verbessern
- Vermeidung langwieriger Feinabstimmungen
- Reduzieren der DLZ, LZ
- Lokalisierung von Schwachstellen und Engpässen
- Bewertung alternativer Konzepte
### Simulation als Entscheidungsgrundlage
- ![image_439.png](image_439.png)
### Anwendungsbereiche
| Bereich | Beispiele für Einsatz |
|----------------------------------------|----------------------------------------------------------------------------|
| Konstruktion und CAD | Bewegungssimulation<br/>Montagemöglichkeiten |
| Fertigung und Logistik | Kapazitätsdimensionen neuer Maschinen<br/>Materialdurchflussuntersuchungen |
| Organisationsgestaltung der Verwaltung | Personalkapazitätsplanungen<br/>Optimierung Arbeitsabläufe |
| Schulungen und Training | Ausbildung und Training neuer Mitarbeiter<br/>Unternehmensplanspiele |
### Ziele
- ![image_440.png](image_440.png)
### Voraussetzungen
- **Vollständigkeit der Modellierung**
- Erfassung von Zeit und Kosten
- Bearbeiterzuordnung
- Subprozesse
- **Angaben über Häufigkeit von Prozessausführungen**
- Prozesskalender
- Bearbeiterkalender
- Prozessmengen
- **Auswertbarkeit von Entscheidungen**
- Variablenbelegung bzw. Attributwerte
- Übergangsbedingungen und Wahrscheinlichkeiten
### Analysegrößen
![image_441.png](image_441.png)
### Vorgehen
![image_442.png](image_442.png)
### Implementierung Simulationsmodell
- Aktivitätssicht des Workflow-Diagramms grafisch nachbilden
- nicht Organisationsschicht
- nicht Informationsschicht
## What-If-Analyse
- Verbesserungsinstrument
- Bewertung von Änderungen auf Unternehmen
- strategische, taktische, operative
- anhand verschiedener Szenarien
- realitätsnah ohne Unterbrechung
- Erlaubt Beantwortung folgender Fragen
- Wie verkürzt sich BZ wenn Ressourcen verdoppelt werden
- Wie hoch ist Kosten-Nutzen-Verhältnis bei verkürzung der BZ
- Wie wirkt sich Veränderung der Arbeitsschichtkonfiguration auf Betriebskosten aus
### Vor-/Nachteile
| Vorteile | Nachteile |
|------------------------------------------------------------|-----------------------------------------------------------------|
| Quantitative Auswertung von komplexen PM | Qualität der Ergebnisse abhängig von Qualität der Eingangsdaten |
| Prüfung von Handlungsalternativen ohne viel Risiko/Aufwand | Definition von Störgrößen problematisch |
| What-If Szenarien | Notwendigkeit der Validierung der Plausibilität |
| Verbesserung Prozessbeherrschung | Realitätsnähe |
| Simultane Auswertung von Informations-/Materialflüssen | Isoliertes, in sich geschlossenes System |
| Identifikation Schwachstellen | erzeugt nicht automatisch entscheidungsreife Vorschläge |
| Auf-/Umbau nicht Notwendig | |
### Simulationswerkzeuge
- Nur mit Computer möglich
## Ebenen der Prozesssimulation (Bizagi)
![image_443.png](image_443.png)
### Ebene 1 - Prozessvalidierung
- Prozess durchläuft alle Sequenzflüsse und verhält sich wie erwartet
- Ressourcen, BZ und Kosten nicht berücksichtigt
- Gateways synchron
- Nachrichten synchron
- Entscheidungswahrscheinlichkeiten korrekt
- Routing wie erwartet
- Alle Token beendet
### Ebene 2 - Zeitanalyse
- End-to-End-Prozesszeit messen
- Ressourcen nicht berücksichtigen
- Best-Case-Szenario unter gegebenen Fluss-/Bearbeitungszeiten
### Ebene 3 - Kalenderanalyse
- Auswirkungen der Ressourcenverfügbarkeit im Laufe der Zeit
- Veränderte Bedingungen
- Feiertagen, Wochenenden, Schichten, Pausen
- Zeigt
- Unter-/Überauslastung
- Gesamtkosten der Ressourcen
- Gesamtkosten Aktivität
- Verzögerungen
- erwartete Zykluszeit
## Beispiel Prozesssimulation
![image_444.png](image_444.png)
- Ergebnis
- ![image_445.png](image_445.png)
### Konfiguration Level 1
- ![image_446.png](image_446.png)
- Ergebnis
- ![image_447.png](image_447.png)
### Konfiguration Level 2
- ![image_448.png](image_448.png)
- Ergebnis
- ![image_449.png](image_449.png)
## Zusammenfassung Simulation
- Methode zur Bewertung der Leistung eines GM
- verschiedene Aspekte
- Zeit, Verfügbarkeit, Kosten
- Ziele:
- Überprüfung der Prozessfähigkeit
- Validierung der Realitätsnähe der Prozessmodelle
- Bewertung alternative PM
- What-If-Analyse nützlich zur Bewertung der Auswirkung auf Unternehmen
- strategische, taktische, betriebliche Änderung

View File

@ -110,4 +110,7 @@
- **Story-Writing-Workshops**
- Meeting mit Devs, Nutzer, Produkt-Kunde, andere Beteiligte
- Schnellste Möglichkeit für neue Stories
- Führen des Workshops benötigt Erfahrung
- Führen des Workshops benötigt Erfahrung
https://www.paypal.com/qrcodes/p2pqrc/Q2JPNYNT3NEQE

View File

@ -100,4 +100,5 @@
## [ARM Toolchain](arm_toolchain.md)
## [ARM Befehle](arm_befehle.md)
## [ARM Befehle](arm_befehle.md)

View File

@ -0,0 +1,130 @@
# ARM Adressierung
## Datentransfer-Befehle
- Einzelregister-Transfer-Befehle (MOV, MVN, MRS, MSR)
- Einzeltransfer-Load/Store-Befehle
- Blocktransfer-Load/Store-Befehle
## Datentransfer
### Datentransfer zwischen Speicher und Register
ldr r0, [r1]
str r0, [r1]
- R0: Zielregister
- R1: enthält Speicheradresse, von der geladen/gespeichert wird
- Langsamer Transfer zwischen Speicher- und Rechenwerk
### Zwischen Registern
mov r0, r1
- R0: Zielregister
- R1: Quellregister
- Schneller Transfer innerhalb des Rechenwerks
## Speicherorganisation
- Byte-orientierter Speicher
- Speicherstelle: **1 Byte**
- Transfer-Befehle liefern meist 32 Bit
- ![image_423.png](image_423.png)
### Little Endian
![image_424.png](image_424.png)
### Alignment im Speicher
- Ausrichtung der Adressen für Zugriffe an Worten (32Bit = 4 Byte)
- ![image_425.png](image_425.png)
- erlaubt einfachere Speicheranbindung, wenn Wortweise gelesen wird
- Cache Speicherung mindestens nach Worten ausgerichtet
- Wenn man Bytes frei anordnen würde, könnte eine Hälfte im Cache stehen, die andere nicht verfügbar
- **Intel:**
- Jedes Wort kann auf jeder Adresse stehen
- nicht ausgerichtete Wörter brauchen 2 Speicherzugriffe
- wäre langsamer
## Speicheraufteilung / Assembleranweisungen
- **.text**
- Legt Textbereich an
- **.align #Bits**
- nachfolgende Anweisung steht auf Speicherstelle, deren unteren #Bits 0 sind
- **.data**
- Legt Datenbereich an
- **.comm symbol, size**
- Legt Symbol in globale bss-Section für uninitialisierte Daten
- **.word Ausdruck**
- Legt initialisierten Speicherbereich mit Größe 4 Byte an
- **.byte Ausdruck**
- Legt initialisierten Speicherbereich mit Größe 1 Byte an
![image_426.png](image_426.png)
## Befehle LDR und STR
- Zugriff erfolgt indirekt
- Speicherung kann indiziert / mit Offset vorgenommen werden
- zum Zugriff genutzter Zeiger kann vor / nach Zugriff in-/dekrementiert werden
![image_427.png](image_427.png)
## Immediate Adressierung
- ![image_428.png](image_428.png)
- Operand wird direkt im Befehl gespeichert
- Kein weiterer Speicherzugriff erforderlich
## Direkte Adressierung
- ![image_429.png](image_429.png)
- Adresse befindet sich im Opcode
- Kann während der Laufzeit nicht mehr geändert werden
- **Achtung:**
- RISC kann nicht 32Bit im Opcode → nicht möglich
## PC-relative Adressierung
- Zugriff auf Daten mit _ldr register, label_
- Laden der ADresse erfolgt über Konstante
- wird PC-relativ adressiert
- Befehl ldr r0, Label
- Pseudobefehl, wird vom Assembler in passenden Befehl umgesetzt
- Beispielsweise:
- ```
add r0, pc, #8
sub r0, pc, #0xb7
ldr r0, [r0]
ldr r0, [pc, #8]
```
- Speicherinhalt an Stelle Label wird geladen
## Pipelining
- ![image_430.png](image_430.png)
- im PC immer aktuelle Befehlsadresse + 8
## Register-Adressierung
- `mov r0, r1`
- ![image_431.png](image_431.png)
- Wie [direkte Adressierung](#direkte-adressierung). nur mit Speicher- statt Registeradresse
### Register-indirekte Adressierung
- Beispiel: `ldr r0, [r1]`
- ![image_432.png](image_432.png)
- Benutzt Registerwert (**Basisregister**) als Speicheradresse
- zum Laden/Speichern des Wertes an der Adresse
- einer der Operanden aus dem Speicher, andere im Register
- Registeradressierung über Pointer
- Gesamter Speicherbereich kann adressiert werden, ohne dass Adresse in der Instruktion sein muss
### Beispiel Kopieren
![image_433.png](image_433.png)
## Indizierte Adressierung
- Register + Offset Adressierung
- Beispiel: `ldr r0, [r1, #8]`
- ![image_434.png](image_434.png)
- Kommt häufig vor, dass Speicher zugegriffen wird, der einen Offset relativ zur Basisadresse besitzt
- Adressierung über Register plus konst. Offset = **indexed Adressing**
- Arm:
- ![image_435.png](image_435.png)
- ![image_436.png](image_436.png)
## Beispiel Kopieren indiziert
- ![image_437.png](image_437.png)
- ![image_438.png](image_438.png)
-

View File

@ -401,3 +401,4 @@
- Inhalt von lr wird zur Rückkehr ins aufrufende Programm benötigt
- ![image_337.png](image_337.png)
## [ARM Adressierung](arm_adressierung.md)