Tips for using Models Based Systems Engineering tools with fprime #2832
Replies: 5 comments 2 replies
-
|
Hey @ReggieMarr, good question, and good timing! There actually is an ongoing effort to look into adding state machines to FPP. The first PR for this was just opened a couple days ago! I will let @gjwatney and @bocchino speak more to it if they want. |
Beta Was this translation helpful? Give feedback.
-
|
Wow great minds must think alike ! One question I have is about the decision to use plantuml. Personally I've been using it for several years to sketch out designs or produce documentation however I've been looking more into wysiwyg editors for a workflow that's more adaptable to folks outside of the software domain (i.e. systems engineers). I see that cameo and qm are also supported by stars would that implicitly work with an fprime based project then? |
Beta Was this translation helpful? Give feedback.
-
|
Phase 1 implementation allows you to define state machines in PlantUML, MagicDraw Cameo or the Quantum Modeling tool. In FPP the developer instantiates the state machine or state machines in the body of the Component along with the priority and the queue full behavior.
So if I want to use PlantUML, I would define my state machine like this:
@startuml
[*] --> ON
state ON {
ON:Entry: turnOn()
}
state OFF {
OFF:Entry: turnOff()
}
ON --> OFF : RTI
OFF --> ON : RTI
@enduml
Then in the FPP I would instantiate it into a component like this:
state machine DevDrv
active component C {
state machine instance dev1: DevDrv priority 1 Drop
state machine instance dev2: DevDrv priority 2 Assert
}
When the FPP is run through the FPP Compiler, the state machine is instantiated in the base class of the Component. The state machine definition in PlantUML is autocoded via the STARS tool and then linked into the Component code.
In Phase 2 the state machine behavior can be defined directly in FPP and the FPP compiler will generate the state machine code. Phase 1 will always be a viable approach as some developers may prefer to specify state machine behavior graphically (MagicDraw or Quantum Modeling) or textually in PlantUML.
Phase 2 FPP will look like this:
state machine DevDrv {
signal RTI
action turnOn
action turnoff
initial enter ON
state ON {
entry do { turnOn }
on RTI enter OFF
}
state OFF {
entry do {turnoff}
on RTI enter ON
}
}
active component C {
state machine instance dev1: DevDrv priority 1 Drop
state machine instance dev2: DevDrv priority 2 Assert
}
Garth
From: Thomas Boyer-Chammard ***@***.***>
Sent: Thursday, August 15, 2024 9:14 AM
To: nasa/fprime ***@***.***>
Cc: Watney, Garth J (US 348C) ***@***.***>; Mention ***@***.***>
Subject: [EXTERNAL] Re: [nasa/fprime] Tips for using Models Based Systems Engineering tools with fprime (Discussion #2832)
Hey @ReggieMarr<https://urldefense.us/v3/__https:/github.com/ReggieMarr__;!!PvBDto6Hs4WbVuu7!JxJPMc1awAEeK3XNcEYqzsyoi38eItfLTDL6cmOtXGjeDwlyvsTiqtk8r98OZH_m0shRDkZ5IdqaToZW2CmOVyniaCE$>, good question, and good timing!
There actually is an ongoing effort to look into adding state machines to FPP. The first PR for this was just opened a couple days ago!
#2829<https://urldefense.us/v3/__https:/github.com/nasa/fprime/pull/2829__;!!PvBDto6Hs4WbVuu7!JxJPMc1awAEeK3XNcEYqzsyoi38eItfLTDL6cmOtXGjeDwlyvsTiqtk8r98OZH_m0shRDkZ5IdqaToZW2CmOm6TsgNc$>. My understanding is that this "Phase 1" implementation is using PlantUML to define state machines, and uses another JPL tool (https://github.com/JPLOpenSource/STARS<https://urldefense.us/v3/__https:/github.com/JPLOpenSource/STARS__;!!PvBDto6Hs4WbVuu7!JxJPMc1awAEeK3XNcEYqzsyoi38eItfLTDL6cmOtXGjeDwlyvsTiqtk8r98OZH_m0shRDkZ5IdqaToZW2CmObZ_ovV0$>) to generate the C++ code.
Later phases will add in the state machine definition and code generation straight into FPP.
I will let @gjwatney<https://urldefense.us/v3/__https:/github.com/gjwatney__;!!PvBDto6Hs4WbVuu7!JxJPMc1awAEeK3XNcEYqzsyoi38eItfLTDL6cmOtXGjeDwlyvsTiqtk8r98OZH_m0shRDkZ5IdqaToZW2CmOw8qaW10$> and @bocchino<https://urldefense.us/v3/__https:/github.com/bocchino__;!!PvBDto6Hs4WbVuu7!JxJPMc1awAEeK3XNcEYqzsyoi38eItfLTDL6cmOtXGjeDwlyvsTiqtk8r98OZH_m0shRDkZ5IdqaToZW2CmOjGzypJo$> speak more to it if they want.
—
Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https:/github.com/nasa/fprime/discussions/2832*discussioncomment-10349831__;Iw!!PvBDto6Hs4WbVuu7!JxJPMc1awAEeK3XNcEYqzsyoi38eItfLTDL6cmOtXGjeDwlyvsTiqtk8r98OZH_m0shRDkZ5IdqaToZW2CmOI39yMCA$>, or unsubscribe<https://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/AUCMOIN3P5LVOCAWCGTOHCDZRTHVDAVCNFSM6AAAAABMO52C42VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZUHE4DGMI__;!!PvBDto6Hs4WbVuu7!JxJPMc1awAEeK3XNcEYqzsyoi38eItfLTDL6cmOtXGjeDwlyvsTiqtk8r98OZH_m0shRDkZ5IdqaToZW2CmOVkMrPAs$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Nice I like the flexibility; |
Beta Was this translation helpful? Give feedback.
-
|
MagicDraw Cameo is supported because of legacy reasons. If someone was starting a new project I would not recommend it, the tool is very heavy weight for just specifying state machine behaviors and has a steep learning curve. The Quantum Modeling tool is a free open source drawing tool for just specifying state machine behaviors. It’s very light weight, easy to use and does the job. PlantUML state machines are for users who want to specify state machine behavior in text. It comes with it’s own graphics renderer. For small to moderate state machine models I would highly recommend using PlantUML, the graphics become unclear for larger models.
Garth
From: Reginald Marr ***@***.***>
Sent: Thursday, August 15, 2024 1:53 PM
To: nasa/fprime ***@***.***>
Cc: Watney, Garth J (US 348C) ***@***.***>; Mention ***@***.***>
Subject: [EXTERNAL] Re: [nasa/fprime] Tips for using Models Based Systems Engineering tools with fprime (Discussion #2832)
Nice I like the flexibility;
Out of curiosity why were plantuml, cameo, and qm selected to be supported ?
They seem like decent choices to me however I'd like to understand the thinking behind it since I'm less familiar with the later two.
—
Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https:/github.com/nasa/fprime/discussions/2832*discussioncomment-10352385__;Iw!!PvBDto6Hs4WbVuu7!L5IdUiK7u0yipy2BXMJGvwxqh1gSc50F7iOws9HTBZzkgpGGMy4NsreZ8zFPlmLb8LjkccyTPI-rQ2NiRtBcMiX3FMg$>, or unsubscribe<https://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/AUCMOINP577265BEAS3QWFTZRUIMJAVCNFSM6AAAAABMO52C42VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZVGIZTQNI__;!!PvBDto6Hs4WbVuu7!L5IdUiK7u0yipy2BXMJGvwxqh1gSc50F7iOws9HTBZzkgpGGMy4NsreZ8zFPlmLb8LjkccyTPI-rQ2NiRtBcQWvSUqs$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
The STARS repo provides a test harness where you can specify a state machine in PlantUML and then execute it while seeing the graphical animation: |
Beta Was this translation helpful? Give feedback.
-
|
So this seems quite appealing to me and my colleagues. @startuml
[*] --> IDLE: /initState()
state IDLE {
IDLE:Exit: initState()
}
state IN_FLIGHT {
[*] --> FIRING
state FIRING {
FIRING:Entry: engageThrust()
}
state GLIDING {
GLIDING:Entry: disengageThrust()
}
state tBurnCheck <<choice>>
FIRING --> tBurnCheck: CHECK_INTERVAL
tBurnCheck --> GLIDING: [isTBurnReached()]
}
IDLE --> IN_FLIGHT: IGNITE/startFlightSim()
IN_FLIGHT --> IDLE: TERMINATE/stopFlightSim()
@endumlI was then able use stars to generate the fpp using this command: Stars.py -backend fprime -namespace FlightComputer -model FlightSequenceSM.plantumlWhich resulted in a bunch of fpp and cpp (main.cpp, SignalGen.cpp, sendEvent.cpp) but most notable was this fpp file: state machine FlightSequencerSM {
action disengageThrust
action engageThrust
action initState
action startFlightSim
action stopFlightSim
guard isTBurnReached
signal CHECK_INTERVAL
signal IGNITE
signal TERMINATE
state IDLE {
exit do { initState }
on IGNITE do { startFlightSim } enter IN_FLIGHT
}
state IN_FLIGHT {
state FIRING {
entry do { engageThrust }
on CHECK_INTERVAL enter J5
}
state GLIDING {
entry do { disengageThrust }
}
initial enter FIRING
on TERMINATE do { stopFlightSim } enter IDLE
}
initial do { initState } enter IDLE
}This seems to match closer to what you @gjwatney described as "Phase 2" fpp and does not compile since the current version of fprime tools doesn't seem to support that kind of syntax. This indicates to me that the STARS project and fprime (or at least fprime-tools) are a bit out of sync. It seems to be a new and fairly large feature so that is understandable however I wonder if I'd be able to get insight into the roadmap here; Specifically is Phase 2/sync'ing STARS expected to be merged as part of v3.5 ? Lastly on a wider note is this something that is expected to work in a complimentary fashion to the command sequencer ? |
Beta Was this translation helpful? Give feedback.
-
Hi All,
I'm looking into a variety of mbse tools to use for generating code based around state machines, activity diagrams, ect.
I've been reviewing the following:
I've found that itemis CREATE and Papyrus are pretty decent for drawing up state machines and generating code associated with them however I found them both a bit tricky to handle for more substantial work and I couldn't figure if they provided much in the way of analysis capability.
EA is a bit more fully featured with it's analysis features and has a decent API.
One tricky aspect here is finding tooling that works well with fprime's paradigm. It does seem a little tricky generating code with multiple tools (i.e. fpp and uml). Has anyone here had experience with this if so how did that go ?
Ideally it would be nice to develop some sort of fprime specific mbse specific tooling however that feels like a mountain I'm not able to climb at the moment.
Beta Was this translation helpful? Give feedback.
All reactions