Differences

This shows you the differences between two versions of the page.

--- statnice:bakalar:b4b35psr [2026/05/30 18:44] – [Off-line rozvrhování] mates1n
+++ statnice:bakalar:b4b35psr [2026/05/30 20:57] (current) – [On-line rozvrhování] mates1n
@@ Line 59: / Line 59: @@
 Tyto **volby nelze udělat nezávisle**, ovšem k jejich učinění lze použít například max-flow grafový algoritmus.
-** Cyklická exekutiva **
+** Cyklická exekutiva (Scheduler spouštící frame-based rozvrh) **
-(fancy název pro rozvrhovač spouštící "frame based" rozvrh)
 V případě, že kombinujeme cyklickou exekutivu s OS, jde o **úlohu/proces s nejvyšší prioritou.**
 Problémy cyklické exekutivy:
@@ Line 67: / Line 67: @@
 ** Odezva aperiodických podúloh **
 Při statickém rozvrhování se aperiodické úlohy vykonávají při volné kapacitě. Ta je buď statickým rozvrhem dána **implicitně** (tj. pevné časové sloty), nebo ji můžeme **optimalizovat** pomocí **kradení rezervy** (Slack Stealing) tak, aby byly aperiodické úlohy splněny co nejdříve, ale periodické úlohy se vykonaly v rámci svého přiděleného frame.
@@ Line 80: / Line 81: @@
 **Rate-Monotonic (RM)** - priorita je určena podle **periody**. Platí - čím nižší perioda, tím vyšší priorita.
-**Deadline-Monotonic (DM)** - priorita je určena podle blízkosti nejzazšího deadline. Platí - čím bližší deadline, tím vyšší priorita.
+**Deadline-Monotonic (DM)** - priorita je určena podle **blízkosti deadline**. Platí - čím bližší deadline, tím vyšší priorita.
 **Ani jeden** z těchto algoritmů **není optimální**. RM rozvrhovač je optimální pouze pro jednoduše periodické úlohy (tj. úlohy, kde pro každé dvě úlohy $ i,j $ platí, že pokud pro periody platí $ T_i < T_k $, pak platí $ T_k = n \cdot T_i; n \in \mathbb{Z} $
@@ Line 86: / Line 87: @@
 == Deadline driven rozvrhování (Dynamic Priority rozhodování) ==
-Nejjednodušší příklad - **EDF** (Earliest deadline first) - vždy se vykonává podúloha s nejbližším termínem nejzazšího vykonání. Tento algoritmus je optimální za podmínek možnosti preempce podúloh a vyloučení zpoždění způsobeného sdíleným přístupem k paměti.
+Nejjednodušší příklad - **EDF** (Earliest deadline first) - vždy se vykonává podúloha s nejbližším deadlinem. Tento algoritmus je optimální za podmínek možnosti preempce podúloh a vyloučení zpoždění způsobeného sdíleným přístupem k paměti.
 == Kombinování real-time a best-effort úloh ==
@@ Line 121: / Line 122: @@
 {{:statnice:bakalar:pasted:20250608-194627.png?400}}
 **Constant Utilization Server** (CUS)
-CUS uvedeme pouze okrajově, protože podle materiálů "The value of the CUS is not clear, and Liu does a terrible job arguing for it!"...
+Uvedeme pouze okrajově, protože podle materiálů "The value of the CUS is not clear, and Liu does a terrible job arguing for it!"...
 Pravidla pro konzumaci budgetu:
@@ Line 134: / Line 136: @@
 ===== Bezpečnostně kritický software =====
-Popište proces vývoje bezpečnostně kritického software:
+=== Proces vývoje bezpečnostně kritického SW ===
-**fáze vývoje**-
+== Fáze vývoje ==
 (Dle MIL-STD-882E)
   - Zdokumentujte jakým způsobem je dosažena bezpečnost
@@ Line 148: / Line 149: @@
-**způsoby zmírňování nepřiměřeného rizika**
+== Způsoby zmírňování nepřiměřeného rizika ==
 Snížení rizik lze docílit následujícími kroky:
@@ Line 164: / Line 165: @@
-** Co je to ”safety integrity level”(SIL)? **
+=== Safety Integrity Level (SIL) ===
+Požadovaná relativní úroveň zabezpečení pro snížení rizika selhání bezpečnostní funkce uplatněním bezpečnostních nároků -> určuje, jak nízká musí být pravděpodobnost nebezpečného selhání.
-Obecně jde o relativní úroveň snížení rizikovosti uplatněním bezpečnostních nároků.
+Úrovně:
-Standard IEC 61508 upravuje úrovně vyžadovaného ochrany proti systematickému selhání v "safety-related" systémech.
+  * SIL 1 - selhání jednou za 10 let
-Obecně - čím vyšší vyžadovaná úroveň SIL, tím nižší je tolerance na "nebezpečná selhání" (dangerous failure). SIL 1 - cca 1 za 10 let, SIL 4 - cca 1 za 10000 let. Toho nelze dosáhnout testováním, využíváme nepřímé způsoby. Vznikají konkrétní nároky na způsob provedení. (nebudu sem dávat screeny, úplně není legální šířit obashy placených standardů :D )
+  * SIL 2
+  * SIL 3
+  * SIL 4 - selhání jednou za 10 000 let
-** Jak a kdy se určí? **
+Určení SIL testováním nemožné (protože nemáme času), místo toho se používají nepřímé metody.
-Jak:
+Vyšší SIL obecně znamená přísnější požadavky na:
-  - Identifikace hazardů - (např HAZOP)
+  * návrh systému
+  * dokumentaci
+  * traceabilitu ("proč je na tomhle místě právě tenhle kus kódu")
+  * verifikaci a validaci
+  * nezávislé kontroly a review
+  * testovací pokrytí
+  * používání formálních metod a doporučených postupů
+== Určení SIL ==
+**Jak:**
+  - Identifikace hazardů - (např. HAZOP)
   - Přiřazení pravděpodobnosti jednotlivých hazardů
   - Identifikace mechanismů jim zabraňujícím
@@ Line 184: / Line 199: @@
 Obecně chceme docílit třídy rizika 4. Systémy se třídou SIL1 mohou snížit rizika o jednu třídu, Systémy se třídou SIL4 mohou snížit  rizika o tři úrovně.
-Kdy:
+**Kdy:**
-SIL se obecně určuje již při plánování - je to jeden z podstatných kroků analýzy bezpečnosti.
+Při **plánování** - je to jeden z podstatných kroků analýzy bezpečnosti.
+== Vliv SIL na vývoj a testování systému ==
-** Jak se různý SIL projeví při vývoji a testování systému? **
 Různé úrovně SIL mají různé nároky - například je třeba pro různé úrovně je vyžadována různá úroveň kontroly korektního fungování a to od formy důkazu korektnosti až po množství lidí, kteří systém zkontrolují. Dále je podstatná míra jejich nezávislosti. Stejně tak jsou doporučené praktiky pro různé úrovně SIL.

Trace: • b4b36zui • b4b35psr

Differences

Search

Navigation

Print/export

Tools

QR Code