Skip to content

Commit

Permalink
Review suggestions
Browse files Browse the repository at this point in the history
  • Loading branch information
LeStarch committed Feb 24, 2025
1 parent 6c37663 commit 469b6f6
Show file tree
Hide file tree
Showing 3 changed files with 16 additions and 8 deletions.
4 changes: 2 additions & 2 deletions docs/user-manual/design-patterns/common-port-patterns.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ Synchronous get ports are used to return values from one component in the F Prim

The callback port patten is used to separate a request port invocation from a following response port invocation allowing the requestor to return to other work while the request is completed. The ports used may be of any type and may contain port arguments to communicate results.

An example of this pattern can be found as part of the [Manager/Worker](https://github.com/fprime-community/fprime-examples/tree/devel/FlightExamples/ManagerWorker) interaction seen in F Prime examples.
An example of this pattern can be found as part of the [Manager/Worker](https://github.com/nasa/fprime-examples/tree/devel/FlightExamples/ManagerWorker) interaction seen in F Prime examples.

```mermaid
sequenceDiagram
Expand Down Expand Up @@ -212,7 +212,7 @@ Asynchronous components performing long-running work inside an `async` port hand
This situation can be remedied by using a `sync` port call to set a cancel flag, which the long-running work can poll to determine if the work should be stopped early.
An example of this pattern can be found as part of the [Worker Component](https://github.com/fprime-community/fprime-examples/tree/devel/FlightExamples/ManagerWorker/Worker) in F Prime examples.
An example of this pattern can be found as part of the [Worker Component](https://github.com/nasa/fprime-examples/tree/devel/FlightExamples/ManagerWorker/Worker) in F Prime examples.
```mermaid
sequenceDiagram
Expand Down
18 changes: 13 additions & 5 deletions docs/user-manual/design-patterns/health-checking.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

Certain services in flight software are critical for the correct execution of the system. For example, command dispatching is crucial to maintain control of the system. It is good practice to monitor these services to ensure they remain responsive during execution of the system. The health checking pattern is used to establish a component as a critical component of the system and periodically check it for responsiveness.

The fprime-examples repository provides an example of the health checking pattern through its [Manager Component](http://github.com/fprime-community/fprime-examples/tree/devel/FlightExamples/ManagerWorker) as the Manager is intended to stay responsive at all times.
The fprime-examples repository provides an example of the health checking pattern in its [Manager Component](http://github.com/nasa/fprime-examples/tree/devel/FlightExamples/ManagerWorker) as the Manager is intended to stay responsive at all times.

## Applicability

Expand All @@ -27,11 +27,11 @@ sequenceDiagram
Component->>-Health: Ping Response
```

`Svc.Health` tracks how long it takes for the component to respond to the ping message placed on its queue. `Svc.Health` will produce a `WARNING_HI` event after a configurable amount of time followed by `FATAL` event after a longer configured time. Thus the system will warn if a component is responsive and follow-up with a system reset if the component remains unresponsive.
`Svc.Health` tracks how long it takes for the component to respond to the ping message placed on its queue. `Svc.Health` will produce a `WARNING_HI` event after a configurable amount of time followed by `FATAL` event after a longer configured time. Thus the system will issue a WARNING_HI event if a component does not respond, and escalate to a FATAL event (triggering a reset or other FATAL handling) if the component remains unresponsive.

## Implementation

Implementation of the health checking pattern involves placing a pair of of `Svc.Ping` ports on your `active` component one as an `async input` and the other as an `output`. Typically these ports are named `pingIn` and `pingOut` respectively.
Implementation of the health checking pattern involves placing a pair of `Svc.Ping` ports on your `active` component, one as an `async input` and the other as an `output`. Typically these ports are named `pingIn` and `pingOut` respectively.

**Component Model Snippet**
```
Expand Down Expand Up @@ -83,8 +83,16 @@ namespace MyTopology {
> [!NOTE]
> This configuration is set for **each instance** of the component. In this example `criticalComponent` is an instance of `CriticalComponent`
## Conclusion
## Testing and Verification

The health checking pattern can be tested by a combination of unit and integration tests. For basic functionality, invoke the `input` Svc.Ping port in a unit test, dispatch the component, and assert the `output` Svc.Ping port returned the supplied key.

Integration tests can be used to test this pattern alongside the Svc.Health component. Set the ping timeout of the component below the minimum time for the component using `HLTH_CHNG_PING` and assert that appropriate WARNING and/or FATAL events occur.

The health checking pattern can be used to ensure critical services within the system remain responsive of the course of the software's execution. Should the component fail to respond for a pair of configurable durations, a WARNING_HI and FATAL event will respectively result.
## Other Considerations

The health checking pattern can be used to test any active component, not just critical ones. However, care should be taken with configured values as Svc.Health will FATAL the system in response to unresponsive components leading to system reset or other FATAL handling actions.

## Conclusion

The health checking pattern can be used to ensure critical services within the system remain responsive over the course of the software's execution. Should the component fail to respond for a pair of configurable durations, a WARNING_HI and FATAL event will respectively result.
2 changes: 1 addition & 1 deletion docs/user-manual/design-patterns/manager-worker.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

The manager/worker pattern is used to perform long-running background work within a component that needs to remain highly responsive to the rest of the system. It is an adoption of the "worker thread" pattern (commonly seen in Computer Science) into the F Prime architecture.

The fprime-examples repository provides an example of the [Manager/Worker Pattern](http://github.com/fprime-community/fprime-examples/tree/devel/FlightExamples/ManagerWorker).
The fprime-examples repository provides an example of the [Manager/Worker Pattern](http://github.com/nasa/fprime-examples/tree/devel/FlightExamples/ManagerWorker).

## Applicability

Expand Down

0 comments on commit 469b6f6

Please sign in to comment.