... | ... | @@ -208,6 +208,12 @@ There are two primary objectives for layering the code: |
|
|
* You should be able to look at any piece of code and assess what it does, where it lives and which other layers and functions it interacts with.
|
|
|
* Each code module should be in a namespace of its own layer that indicates its intent and describes where it fits in the hierarchy.
|
|
|
|
|
|
#### System Architecture
|
|
|
![Platform_Architecture-System_Architecture](uploads/fc8e94079d6622247ab119f029f40e38/Platform_Architecture-System_Architecture.png)
|
|
|
|
|
|
#### Software Architecture
|
|
|
![Platform_Architecture-Software_Architecture](uploads/428707811b400f06074d31fef8aaf5e0/Platform_Architecture-Software_Architecture.png)
|
|
|
|
|
|
The layers are:
|
|
|
|
|
|
* `app_ `: Application Layer
|
... | ... | @@ -224,22 +230,8 @@ The layers are: |
|
|
* The OS layer provides a common abstraction layer from the underlying operating system (OS). This allows the code to be portable to any ECU, regardless of the underlying OS, even a bare-metal system.
|
|
|
* `sl_ `: Standalone and Utility Library Layer
|
|
|
* Code modules in this layer are implemented as pure functions or utility macros, or define standard types. These modules have no internal state, do not have external dependencies, and do not have run tasks. They are mathematical libraries, conversion functions, or standardized type definitions. The only external dependencies allowed would be other standard utility library modules.
|
|
|
|
|
|
Example 1:
|
|
|
`sl_crc32` only operates on data passed as parameters to it's API. It operates on the parameters and returns a result. It does internally store any data, and therefore contains no internal state or memory.
|
|
|
|
|
|
Example 2:
|
|
|
`sl_uds_server` is a complex module that depends on other `SL` modules, but still does not store any data internally. All information is passed via parameters to the API. Any static information is stored within the application that creates an instance of `sl_uds_server`, and simply uses the `sl_uds_server` API to opperate on that instance.
|
|
|
|
|
|
### More about our Architecture and Layers
|
|
|
|
|
|
#### System Architecture
|
|
|
![Platform_Architecture-System_Architecture](uploads/fc8e94079d6622247ab119f029f40e38/Platform_Architecture-System_Architecture.png)
|
|
|
|
|
|
#### Software Architecture
|
|
|
![Platform_Architecture-Software_Architecture](uploads/428707811b400f06074d31fef8aaf5e0/Platform_Architecture-Software_Architecture.png)
|
|
|
|
|
|
</details>
|
|
|
* _Example 1:_ `sl_crc32` only operates on data passed as parameters to it's API. It operates on the parameters and returns a result. It does internally store any data, and therefore contains no internal state or memory.
|
|
|
* _Example 2:_ `sl_uds_server` is a complex module that depends on other `SL` modules, but still does not store any data internally. All information is passed via parameters to the API. Any static information is stored within the application that creates an instance of `sl_uds_server`, and simply uses the `sl_uds_server` API to opperate on that instance.
|
|
|
|
|
|
## Double Underscore
|
|
|
|
... | ... | |