Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Extensive modelling of simple System-wide Mode Change capabilities #41

Merged
merged 12 commits into from
Mar 21, 2023
Merged

Extensive modelling of simple System-wide Mode Change capabilities #41

merged 12 commits into from
Mar 21, 2023

Conversation

chgio
Copy link
Member

@chgio chgio commented Feb 25, 2023 •
edited
Loading

This MR integrates the work done in model/gio-obc-relayed-bypassing-mode-change (#26; never merged) and in model/gio-auto-mode-change-link-sensing (no PR, stale branch), adopting a new, simplistic perspective on modelling these features to produce a comprehensive model of all mode changes.

MBSE is a strictly top-down engineering process, but our limited means force us to inject extremely tight bottom-up requirements!

Auto Mode Changes regulate the nominal transitions between Primary and Secondary State Loops, only activating one of the two Subsystem Groups at a time:

  • Link State Loop Entry, activating Comms (and EPS)
  • Sensing State Loop Entry, Progress, Exit, activating Payload or Pipeline (and EPS)

Telecommanded Mode Changes only concern Mission Activities, and instantaneously force custom activation of Subsystems within the Sensing Group while progressing the Link State Loop as any telecommand:

  • trigger Mission Idling
  • trigger Mission Imaging Mode
  • trigger Mission Processing Mode

In order to prevent the architecture from imposing excessively tight requirements on the Communications Subsystem, no recovery transitions are specified, and robustness/resiliency measures are kept to a minimum:

  • half-star topology -- the OBC relays packets from Comms to the rest of the System, being a Single Point of Failure
  • minimal Comms functionalities:
    • polled action
    • buffer packets (RX/TX)
    • dump packets (RX)
    • flush packets (TX)

Mission Activities are also included and expanded to illustrate the different functionalities active in different states:

  • Image Capture
  • Image Transfer (Payload -> Pipeline)

Giorgio Ciacchella added 7 commits February 21, 2023 22:05
[FEATURE] SIMPLE MODE CHANGING & MISSION FUNCTIONS @ SYSTEMS LEVEL
3db7806 
in [SFBD] Root System Function Breakdown:
- add functions to set auto Area of Interest as an auto mode change
  parameter
- add payload images downlink request functions
- add telemetry downlink request functions
- rename downlink functions to only mention "telemetry" for generality:
  distinction between housekeeping data and mode change reports should
  be at a lower level

rename the main [SAB] to *Root* System Architecture, and:
- allocate functions following the sam paradigm:
	- "issue" fns to G/S Op.
	- "send TC / receive TM" fns to G/S
	- "receive TC / send TM" fns to System
	- "monitor" fns to System (internal polling)
- create functional chains to highlight the centrality of mode changes
  for most telecommands: apart from the explicit mode change commands,
  requests for data imply a switch from uplink to downlink in order to
  be responded to

create clones of main [SAB] to highlight those functional chains:
- [SAB] System Architecture View of Mode Changes
	- Auto mode changes:
		- sensing state loop entry
		- sensing state loop progress
		- link state loop entry (progresses involve
		  human-in-the-loop)
- [SAB] System Architecture View of Telecommands
	- Area of Interest configuration
	- telecommanded mode change
	- retrievals:
		- telemetry
		- payload images

fix [ES] Commanded Mode Change Scenario, and decorate it with relevant
states from the FSM;
create [ES] Nominal Mission Operation Full Scenario, illustrating
end-to-end all the main operational functionalities in the model:
- sensing loop traversal
- link loop traversal:
	- contact establishment
	- exploitation of uplink state for AoI configuration
	- exploitation of downlink state for payload image retrieval
	- return to idle

also allocate relevant functional exchanges to transition triggers in
[MSM] System States, and compile States vs Functions matrix for new
additions.

Close #32
Close #33
[FIX] COMMANDED MODE CHANGE CONSTRAINTS
f629899 
constrain commanded mode change operations to mission-related switches,
modelled as immediate changes from any-Uplink state (implementing some
mission-related function) to any-other-Downlink state (implementing some
different mission-related function)

[MSM] System States:
- remove transitions from any non-loop-endpoint state to Idle
- add transitions from any "X & Uplink" to any "!X & Downlink" state
- assign "Mode change TC transmission" trigger to
  "X & Uplink" -> "!X & Downlink" transitions (forced loop switch)
- remove "Mode change TC transmission" trigger from
  "X & Uplink" -> "X & Downlink" transitions (regular loop traversal)
- reformat transition lines for readability -- maybe not clarity, but
  readability

[ES] Commanded Mode Change:
- add all "X & Uplink" states as source system states
- add all "X & Downlink" states as target system states
- add notes describing the "any of" logic instead of sequentiality
[FIX] FIX COMMANDED MODE CHANGE TRANSITION NAMES
084905c 
remove duplicate names from mode change transitions in [MSM] System
States.

names follow this format:
"
	Immediate Mission [target mission activity]
	from SSL1 Stage [state # in SSL1]
"

SSL1 (Secondary Sensing Loop 1) is the constant there, as it includes
all "X & Uplink" states.
[FEATURE] SIMPLE MODE CHANGING & MISSION FUNCTIONS @ LOGICAL LEVEL
ed18d95 
apply transition from System Analysis to Logical Architecture levels.

in [LFBD] Root Logical Function Breakdown:
- expand "Change mode" into a main manager function and
  subsystem-specific "satellite" functions
- expand "Collect telemetry" into:
	- a system mode change report collection tree
	- a payload image collection tree
	- a placeholder function for telemetry datapoint collection
- expand "Send telemetry" into cases for each tree, plus a storage
  function
- expand "Monitor X" into measurement and boundary-crossing functions
- remove mode change validation function -- conceptually substituted by
  report collection
(no expansions on actor functions, even though it breaks symmetry)

in [LAB] Root Logical Architecture:
- allocate functions to their appropriate subsystems
	- although definitely boundary-crossing, the exact communication
	  paradigm (polling/interrupts) belongs in the physical level
- create new functional chains selecting the appropriate path, and set
  each to realise its system-level counterpart

create clones of main [LAB] to highlight those functional chains:
- [LAB] Logical Architecture View of Mode Changes
	- Auto mode changes:
		- sensing state loop entry
		- sensing state loop exit (renaming its system-level
		  counterpart)
		- link state loop entry
	- Telecommanded mode change
- [LAB] Logical Architecture View of Telecommands
	- Area of Interest configuration
	- Telecommanded mode change
	- retrievals:
		- telemetry
		- payload images

in all [MSM] X States:
- allocate relevant functions as "do" blocks to subsystem states
- allocate relevant functional exchanges as transition triggers
	- the upstream trigger of the mode change function when
	  possible;
	- "X mode change command" otherwise;
(formally, this would always be "X mode change command" as issued by the
OBC; however, unless displaying trigger descriptions instead of the
triggers themselves, this would not be very informative)

also delete both [ES] Scenarios; additions will follow.

Close #34
Close #35
[FIX] DELETE OUTDATED LOGICAL SCENARIOS
fd8839a 
delete outdated Exchange Scenario diagrams from Logical Architecture level:
- [ES] Commanded, OBC-Relayed Mode Change Scenario
- [ES] Commanded, OBC-Bypassing Mode Change Scenario

the entire concept just doesn't apply to such a simple architecture.
[FIX] DELETE DUPLICATE LOGICAL FUNCTIONAL CHAIN
40df199 
delete the auto-inherited copy of "Auto mode change (Sensing entry)",
and set its curated version to realise the original chain at System
Architecture level.
[FEATURE] TELECOMMAND MODE CHANGE LOGICAL SCENARIO
553ef74 
create [ES] Commanded Mode Change Logical Scenario at Logical
Architecture level, illustrating the possible phases of telecommanded
mode changes:
- transmission of mode change command
- change of Comms mode
- optional change of Payload mode (ALT block)
- optional change of Software pipeline (ALT block)
- transmission of mode change report
- final change of Comms mode back to idle

also rename System-level scenario to [ES] Commanded Mode Change System
Scenario, and add final system mode change to idle/mission-op for
explicitness

Ref #34
Ref #35
@chgio chgio added obc Within the scope of the On-Board Computer Subsystem system Outside the scope of any single Subsystem labels Feb 25, 2023
@chgio chgio requested a review from DiegoHDLH February 25, 2023 19:01
@chgio chgio self-assigned this Feb 25, 2023
@Jstephenson808 @bobtailcat00
@LiamHepburn @Sajtospoga01 @muhamedshaheenar
[FEATURE] SIMPLE MODE CHANGING & MISSION FUNCTIONS @ PHYSICAL LEVEL
8000708 
apply transition from Logical Architecture to Physical Architecture
levels for CloudView mission -- at this point, the architecture
necessarily becomes too coupled to the actual mission implementation to
be kept generic.

in [PFBD] Root Physical Function Breakdown:
- expand "Change system mode" into a system-wide state-tracking function
  and subsystem-specific "satellite" notification functions
- expand the "Collect telemetry" trees:
	- mode change report collection
		- "Receive subsystem mode change report" into subsystem
		  mode change report relays
		- "Collate system mode change report" into buffering and
		  flushing
	- payload image collection
		- "Send raw images" to PWM signals and file access
		  functions
		- "Receive raw images" to file access functions
- expand "Capture images" into timing, PWM signals, capture, and storage
- expand "Attempt Ground Station contact" into receive, buffer, polling
  and logic

in [PCBD] Root Physical Component Breakdown:
- break down OBC Process into:
	- system mode management group:
		- system-wide mode tracker
		- system-wide mode change report collector
		- subsystem-specific mode management components
	- Ground Station contact manager
	- Area of Interest manager
	- Processing progress manager
- create programmable node PCs for:
	- OBC
	- EPS
	- Pipeline
- create non-programmable node PCs for:
	- Comms
	- Payload Camera
- rename non-programmable behaviour PCs to "X Behaviour" instead of
  "X Process"

in [PAB] Root Physical Architecture:
- allocate functions to their appropriate behaviour components
	- system mode management to OBC:
		- system mode tracking and notification call to main
		  mode manager
		- subsystem mode change notifications and relays to
		  respective "satellite" notifiers
		- mode change report buffering and flushing to report
		  collector
	- comms polling and logic to OBC Ground Station contact manager
	- realised functions to OBC Area of Interest manager
	- image capture:
		- image capture timing and PWM sending to Payload
		  Subsystem Process
		- image capture PWM receiving and capturing to Camera
		  Behaviour
	- image transfer:
		- image transfer PWM sending to OBC Processing progress
		  manager
		- image transfer PWM receiving and file exposure to
		  Camera behaviour
		- image transfer mounting and file access to Software
		  Pipeline Subsystem Process
- allocate behaviour components to their appropriate node components
	- "thin" Subsystem Processes for Deployer, ADCS, and Payload to
	  OBC MCU
	- everything else to its own node PC
- create new functional chains selecting the appropriate path, and set
  each (when applicable) to realise its logical-level counterpart
	- Auto mode changes:
		- sensing state loop entry
		- sensing state loop exit
		- link state loop entry
	- Telecommanded mode change
	- Area of Interest configuration
	- Telecommanded mode change
	- Retrievals:
		- telemetry
		- payload images
	- Image capture
	- Image processing:
		- start
		- end
	- Payload image retrieval

create [PDFB] diagrams to highlight the same functional chains, and the
breakdown of functions throughout them:
- [PDFB] Physical Function Dataflow View of Mode Changes
- [PDFB] Physical Function Dataflow View of Telecommands
- [PDFB] Physical Function Dataflow View of Mission Activities

and clone main [PAB] to highlight those functional chains, and the
crossing of component boundaries throughout them:
- [PAB] Physical Architecture View of Mode Changes
- [PAB] Physical Architecture View of Telecommands
- [PAB] Physical Architecture View of Mission Activities

create Functional Chain Descriptions, one per relevant functional chain:
- [PFCD] Functional Chain Description of Telecommanded Mode Change
- [PFCD] Functional Chain Description of Auto Mode Change (Sensing Entry)
- [PFCD] Functional Chain Description of Auto Mode Change (Sensing Exit)
- [PFCD] Functional Chain Description of Auto Mode Change (Link Entry)
- [PFCD] Functional Chain Description of Image Processing (Start)
- [PFCD] Functional Chain Description of Image Processing (End)
- [PFCD] Functional Chain Description of Telemetry Retrieval
- [PFCD] Functional Chain Description of Payload Image Retrieval

also delete both [ES] Scenarios, and create [ES] Commanded Mode Change
Physical Scenario, expanding the namesake Logical Scenario:
- incoming transmission of mode change command
- system mode change
- notification of individual subsystems
- subsystem mode changes
	- Comms
	- Payload (optional, ALT block)
	- Software pipeline (optional, ALT block)
- mode change report collection and flushing
- outgoing transmission of mode change report
- final change of Comms mode back to idle
- final, optional change of EPS mode back to idle

Close #42
Close #43
Close #44
Close #45

Co-authored-by: James Stephenson <jstephenson808@gmail.com>
Co-authored-by: Fang Jan Lim <limfangjan55@gmail.com>
Co-authored-by: Liam Hepburn <liamhepburn619@live.co.uk>
Co-authored-by: Andras Bodrogai <abodrogai@gmail.com>
Co-authored-by: Muhamed Shaheen Abdul Rafiq <muhamedshaheen2002@gmail.com>
@chgio chgio force-pushed the model/gio-mode-change-integrated branch from c9ba2c4 to bc6938a Compare March 13, 2023 12:32
[FIX] DELETE OUTDATED PHYSICAL SCENARIOS
8faf45c 
delete outdated Exchange Scenario diagrams from the Physical
Architecture level:
	- [ES] Commanded, OBC-Relayed Mode Change Scenario
	- [ES] Commanded, OBC-Bypassing Mode Change Scenario
@chgio chgio force-pushed the model/gio-mode-change-integrated branch 2 times, most recently from 07916ea to 8faf45c Compare March 13, 2023 12:57
DiegoHDLH
DiegoHDLH approved these changes Mar 13, 2023
View reviewed changes
Copy link

@DiegoHDLH DiegoHDLH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good shit

@chgio
Copy link
Member Author

chgio commented Mar 13, 2023 •
edited
Loading

  • make "Pipeline Subsystem mode change" chain segments go through "Send PWM file transfer signal"

[FEATURE] SENSING STATE LOOP AUTO MODE CHANGE PHYSICAL FC
f1bb0b3 
add physical-level functional chain representing Automatic Mode Change
(sensing state loop progress):

- in [PAB] Root Physical Architecture, add functional exchange between
  "Notify Pipeline of mode change" and "Send PWM file transfer signal"
- create [PFCD] Physical Functional Chain Description of Auto Mode
  Change (Sensing Progress), with the following steps:
	- location measurement and AoI matching
	- Payload mode change
	- EPS mode change
	- PWM file transfer trigger
	- Pipeline mode change
- add functional chain (and relevant elements) to:
	- [PAB] Physical Architecture View of Mode Changes
	- [PDFB] Physical Function Dataflow of Mode Changes
	- [PAB] Physical Architecture View of Telecommands
	- [PDFB] Physical Function Dataflow of Telecommands

also remove EPS involvement from [PFCD] Functional Chain Description of
Telecommanded Mode Change

Ref #41
@chgio
Copy link
Member Author

chgio commented Mar 14, 2023 •
edited
Loading

  • make functional exchange between "Notify subsystems of mode change" and "Change system mode" to explicitly represent return path, and
  • refactor functional chains (and [ES]! to go through that after all subsystem mode changes

[FIX] EXPLICIT END OF SYSTEM MODE CHANGE RETURN PATH
c70e024 
add physical-level functional exchange from "Notify subsystems of mode
change" to "Change system mode", explicitly representing the return path
at the end of every system mode change.

edit all relevant [PFCD] to route mode change chains through it, and
format its layout in all [PAB] and [PDFB].

Ref #41
@chgio chgio force-pushed the model/gio-mode-change-integrated branch from b399e27 to b78836a Compare March 21, 2023 10:01
[FIX] REFACTOR COMPLEX MODE CHANGE FCs TO REFERENCE SIMPLE S/S BLOCKS
b3af60c 
at Logical Architecture level:
- create simple functional chains for every subsystem mode change and
  related [LFCD] description
- refactor complex system-wide mode change functional chains into
  connected blocks of simple subsystem-specific mode changes
- create Auto Mode Change (Sensing Progress) functional chain adopting
  the same principle
- add second functional exchange between Loc-AoI comparison and system
  mode change to illustrate exit
- add return functional exchange from subsystem mode change report
  reception to system mode change

also remove "Subsystem Matrix: States vs Functions"

at Physical Architecture level:
- realise logical functional chains for subsystem mode changes in
  related [PFCD] description
- refactor physical functional chains for system-wide mode changes into
  connected blocks of subsystem-specific mode changes
- rename [PFCD] diagrams to "Physical Functional Chain Description of X"

Close #46
@chgio chgio force-pushed the model/gio-mode-change-integrated branch from b78836a to b3af60c Compare March 21, 2023 10:01
@chgio chgio merged commit 2efb48e into main Mar 21, 2023
@chgio chgio mentioned this pull request Mar 22, 2023
Closed
3 tasks
This was referenced Apr 5, 2023
Open
Open
@chgio chgio mentioned this pull request Sep 5, 2023
Merged
@chgio chgio mentioned this pull request Jan 25, 2024
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@DiegoHDLH DiegoHDLH DiegoHDLH approved these changes

Assignees

@chgio chgio

Labels
obc Within the scope of the On-Board Computer Subsystem system Outside the scope of any single Subsystem
Projects
None yet
Milestone
System-Wide Mode Change Capability
Development

Successfully merging this pull request may close these issues.
2 participants
@chgio @DiegoHDLH