docs: lifecycle feature

[ramceb]

Feature: #909

[github-actions]

The created documentation from the pull request is available at: docu-html

[FScholPer]

Coming from FEO Error Handling:

• maximum threshold until startup done should be handled. Do we have a definition for hard/soft thresholds? -> handle same or not?
• In this phase memory allocation is problematic and should end up in error state
• There should be some kind of error or emergency state and safety related problems should be handled
• There should be also some kind of suspend error handling and reset state of activities in the chain
• Not only state errors should be handled.
• Activities can raise errors and also problems regarding com API or external Ressources like GPU/NPU should be handled.
• Abrupt shut down of GPUs for example can lead to memory/cache incomplete / inconsistent or corrupted state there.
• Timing above configured thresholds should raise errors. There is a difference between Estimated worst-case Execution time, actual Worst-Case Execution time and Theoretical Worst-Case Execution time. This depends on criticallty levels of activities. Also activities without any upper bound can exist and should not raise any error.
• Logging in case of error is also a missing part .
• Safety error reporting should also use another channel like the normal communication to prevent interference in case of safety problems.
• Errors can change the flow to some kind of degragation or emergency flow. This is not defined currently.
• Do we want to handle SoC problems like undervoltage, overvoltage, temperature and so on?
• Error handling of different ASIL levels should not interfere or share same resources
• Freeing resources should be part of the middleware -> Error handling if not possible
• On startup resource exhaustion should lead to emergency state
• Validation step for the graph is needed to ensure things like connections are correct or strange relationships found before start > error thrown
• I think we need error handling as stakeholder requirement

[jaakkomaho]

I think we could write a liitle bit more about the component dependencies:

• how are dependeing components started?
• How is a component "ready" so that the depending components are allowed to be started?
• How are components getting shutdown? Provide examples of the "mode change" Probably it's a good idea to shutdown the apps in a reverse order of the startup
• What kind of dependices are supported. For example, in PLMS you can have "session" and "stateless", in SystemD I think there are many relations, maybe we'll only pick a few of them

[ZoranCutura]

Minor remarks on terms defined. Otherwise the concept is good.

[ZoranCutura]

Does this actually start and stop processes or request the operating system to do so? see procmgr

[ramceb]

So far the launch manager is intended to do the fork.