Tips for using Models Based Systems Engineering tools with fprime

[ReggieMarr]

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:

• itemis CREATE (previously yakindu)
• Papyrus
• Enterprise Architect

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.

[thomas-bc]

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!
#2829. 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) to generate the C++ code.
Later implementation phases plan to add in the state machine definition and code generation straight into FPP.

I will let @gjwatney and @bocchino speak more to it if they want.

[ReggieMarr]

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?

[gjwatney]

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: ***@***.***>

[ReggieMarr]

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.

[gjwatney]

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: ***@***.***>

[garthwatney]

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:
https://github.com/JPLOpenSource/STARS/tree/main/testharness

[ReggieMarr]

So this seems quite appealing to me and my colleagues.
After seeing phase 1 was merged in by @LeStarch I put together a brief example using the latest version of fprime which looks something like this:

@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()
@enduml

I was then able use stars to generate the fpp using this command:

Stars.py -backend fprime -namespace FlightComputer -model FlightSequenceSM.plantuml

Which 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 ?
Also how is this meant to be integrated into a wider project ?
Currently I have something like an orchestrator which includes the generated fpp files and then sends signals based on sensor/simulation feedback.

Lastly on a wider note is this something that is expected to work in a complimentary fashion to the command sequencer ?