search

guorbit / obc-model

Functional/Architectural Capella 6.0 model for the ASTRAEUS-01 spacecraft system and all its subsystems.
https://guorbit.github.io/obc-model/
12 stars 1 forks source link

Physical Architecture: S/S Bug-Squashing Firmware Reprogram #53

Open Hello-1122 opened 1 year ago

Hello-1122 commented 1 year ago

Existing diagrams to extend:

New diagrams to create:

chgio commented 1 year ago

2 possible approaches to implementing this feature were identified, and the advantages and disadvantages of each were discussed.

1. "Hardware" bootloading

the fundamental characteristic of this approach is writing to flash directly from the serial bus:

sequenceDiagram
    participant obc as OBC
    participant target as Target S/S

    activate obc
    obc ->> target      : trigger boot mode
    activate target
    target -->> obc     : boot mode ok
    obc ->> target      : new firmware
    target ->> target   : write from bus into flash
    target -->> obc     : write ok

    target ->> target   : reset
    deactivate target

    target ->> obc      : heartbeat
    activate target
    deactivate target
    deactivate obc

2. "Software" bootloading

sequenceDiagram
    participant obc as OBC
    participant target as Target S/S
    participant rom as S/S Non-Volatile Memory

    activate obc
    obc ->> target      : new firmware
    activate target
    target ->> rom      : new firmware
    activate rom
    rom -->> target     : write ok
    deactivate rom
    target -->> obc     : write ok
    deactivate target

    obc ->> target      : trigger boot mode
    activate target
    target ->> rom      : load from storage into flash
    activate rom
    rom -->> target     : new firmware
    deactivate rom
    target ->> target   : reset
    deactivate target

    target ->> obc      : heartbeat
    activate target
    deactivate target
    deactivate obc

Comparison and Choice

method pros cons
hardware simple: implementation only involves the OBC writing the new firmware to the serial bus restrictive: imposes on the Target S/S MCU the requirement of featuring serial bootloading from the specific serial bus in use throughout the system (most likely I2C)
software complex: implementation involves an additional component (a non-volatile memory module, likely external to begin with), plus the Target S/S to relay incoming bus reads as storage writes and to load storage reads to flash writes -- on top of the tasks involved in the hardware approach permissive: does not impose any specific COTS requirements on the Target, other than the bare minimum of writeable flash

considering the above tradeoffs, we are opting for the software method, valuing permissiveness over simplicity.

This is mainly because, given the extreme limitations of our financial and technical means, it may very well be impossible to find a Target MCU that satisfies these specific serial interface requirements and all those imposed by its S/S.
On the other hand, the introduced complexity seems manageable, and could even come in handy for further robustness features, such as duplicating backup firmware storage on the Target S/S itself.
At any rate, this cost is better paid upfront than later with interest; conversely, switching from this approach to its counterpart should make for easier implementation, and is always an option if the Target MCU supports it.