diff --git a/docs/design/_assets/OpenSOVD-design-highlevel.drawio.svg b/docs/design/_assets/OpenSOVD-design-highlevel.drawio.svg
index f51e2e5..7dd7b6c 100644
--- a/docs/design/_assets/OpenSOVD-design-highlevel.drawio.svg
+++ b/docs/design/_assets/OpenSOVD-design-highlevel.drawio.svg
@@ -1,1221 +1,4 @@
-
+
+
+
+
diff --git a/docs/design/design.md b/docs/design/design.md
index 769c3ed..8e93408 100644
--- a/docs/design/design.md
+++ b/docs/design/design.md
@@ -23,7 +23,7 @@ The intent of this document is to define a high-level architecture - the compone
The proposed concept consists of three main parts:
-1. A framework agnostic library to aggregate faults and integrate the diagnostic system into a target platform software stack such as S-CORE
+1. A framework agnostic library to aggregate faults and diagnostic data and integrate the diagnostic system into a target platform software stack such as S-CORE
2. A SOVD based diagnostic system
3. Components to interface the diagnostic system with the outside – e.g. Tester or UDS based ECUs
@@ -58,6 +58,22 @@ Their functionality is briefly described below.
- Also needs to enforce regulatory requirements for certain faults - e.g. emission relevant.
- Decentral component.
+- Diagnostic Library
+ - Provides a framework agnostic interface for arbitrary apps and components to register and expose SOVD data resources.
+ - **The Diagnostic Library is also an interface between S-CORE and the OpenSOVD project and should be developed in cooperation - see [ADR S-CORE Interface](./adr/001-adr-score-interface.md).**
+ - Relays diagnostic resources via IPC to the SOVD Server, which exposes it through the SOVD resource API e.g. (`/{entity-path}/{resource-collection}/{resource-id}`).
+ - Supports SOVD resource types as defined by SOVD, including:
+ - Data: static and dynamic data values such as identifications, measurements, and parameters (read/write).
+ - Operations: executable diagnostic objects such as I/O controls, routines, and software functions (synchronous or asynchronous execution).
+ - The interface needs to be specified further but will likely include:
+ - Data resource identifier (unique string identifier per Entity)
+ - DataCategory as defined by SOVD (identData, currentData, storedData, sysInfo, custom)
+ - Data type/schema (OpenAPI Schema Object)
+ - Data group assignment (optional logical grouping)
+ - Read and write access support
+ - Can be used by platform components to expose diagnostic data resources.
+ - Decentral component.
+
- Diagnostic Fault Manager
- Aggregates and manages diagnostic fault data from Fault libs across the system.
- Provides centralized fault status to the SOVD Server.
@@ -118,6 +134,55 @@ Their functionality is briefly described below.
- UDS transport layer (e.g. DoIP or other vendor specific transports) shared with Classic Diagnostic Adapter.
- Central component and unique per ECU/System (one per ECU or per System is possible).
+### Example Topology: SOVD Entity Hierarchy
+
+All apps and components register themselves and their capabilities via the **Diagnostic Library**. Alternative ways to discover and register components and apps are provided, e.g. **mDNS**.
+
+Resources like `faults/` are provided by the **FaultManager**. Resources like `data/`, `operations/`, etc. are provided by the apps directly.
+
+> **Note:** The SOVD entity types `areas`, `subareas`, and `subcomponents` are intentionally omitted from this example for simplicity.
+
+```
+SOVDServer
+├── components/
+│ ├── Hpc1 (current compute unit)
+│ │ ├── data/
+│ │ └── faults/
+│ ├── Ecu1 (classic ECU - exposed by Sovd2Uds)
+│ │ ├── data/
+│ │ └── faults/
+│ └── EcuN (classic ECU - exposed by Sovd2Uds)
+│ ├── data/
+│ └── faults/
+├── apps/
+│ ├── FaultManager (central fault manager, is-located-on Hpc1)
+│ │ ├── data/
+│ │ ├── faults/ (does not aggregate faults from other apps)
+│ ├── App1
+│ │ ├── data/
+│ │ └── faults/
+│ ├── AppN
+│ │ ├── data/
+│ │ └── faults/
+│ ├── Sovd2Uds (Classic Diagnostic Adapter)
+│ │ ├── data/
+│ │ └── faults/
+│ └── Uds2Sovd (UDS-to-SOVD Proxy)
+│ ├── data/
+│ └── faults/
+└── functions/
+ └── VehicleHealth (cross-entity fault view)
+```
+
+#### Entity Relations
+
+| Relation | Request | Returns |
+|---|---|---|
+| `hosts` | `GET /components/Hpc1/hosts` | {FaultManager, App1..N, Sovd2Uds, Uds2Sovd} |
+| `is-located-on` | `GET /apps/{FaultManager,App1..N,Sovd2Uds,Uds2Sovd}/is-located-on` | Hpc1 |
+| `hosts` | `GET /components/Ecu{1..N}/hosts` | *(classic ECU apps exposed by Sovd2Uds)* |
+| `depends-on` | `GET /functions/VehicleHealth/depends-on` | FaultManager |
+
### Out of scope components
The following components are out of scope of the project but are included for context.