Merge branch 'develop-ros-logic' into develop. Close #244.

**Description**

The current ROS backend is overly specific, complex and composes data
manually. For example, it assumes a specific structure for the message
handlers. It also extracts data from data structures, manually converts
it to strings, and then packs it into a JSON structure.

This limits user's abilities to adjust the template to fit their needs,
since most of the data is given as fixed strings (e.g., variable
declarations are given as multiple lines, rather than letting users
access each variable declaration and, within them, each type and name
individually.

It would be better to make more raw data available to the template, and
have the template present the data as needed. That would likely also
decrease the differences across backends, making the code easier to
maintain.

**Type**

- Feature: Make backend more versatile.

**Additional context**

None.

**Requester**

- Ivan Perez.

**Method to check presence of bug**

Not applicable (not a bug).

**Expected result**

The ROS template has raw structured data available about the different
portions of the application, and can be adjusted to present it as
needed.

The following Dockerfile checks that generating a ROS 2 application with
and without the feature proposed renders the same result, after which it
prints the message "Success". It requires an additional BASE_COMMIT
variable pointing to a commit prior to merging this feature.

```
FROM ubuntu:focal

ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update

RUN apt-get install --yes \
      curl g++ gcc git libgmp3-dev libz-dev make pkg-config

RUN mkdir -p $HOME/.local/bin
ENV PATH=$PATH:/root/.local/bin/

RUN curl https://downloads.haskell.org/~ghcup/0.1.17.7/x86_64-linux-ghcup-0.1.17.7 -o $HOME/.local/bin/ghcup
RUN chmod a+x $HOME/.local/bin/ghcup

ENV PATH=$PATH:/root/.ghcup/bin/
RUN ghcup install ghc 9.10
RUN ghcup install cabal 3.12
RUN ghcup set ghc 9.10.1
RUN cabal update

SHELL ["/bin/bash", "-c"]
CMD git clone $REPO \
    && cd $NAME \
    && git checkout $BASE_COMMIT \
    && cabal install ogma-cli:ogma \
    && ogma ros --app-target-dir original --variable-file ogma-cli/examples/ros-copilot/variables --variable-db ogma-cli/examples/ros-copilot/vars-db --handlers-file ogma-cli/examples/ros-copilot/handlers \
    && git checkout $COMMIT \
    && cabal install --overwrite-policy=always ogma-cli:ogma \
    && ogma ros --app-target-dir updated  --variable-file ogma-cli/examples/ros-copilot/variables --variable-db ogma-cli/examples/ros-copilot/vars-db --handlers-file ogma-cli/examples/ros-copilot/handlers \
    && diff -rq original updated \
    && echo "Success"
```

Command (substitute variables based on new path after merge):
```sh
$ docker run -e "REPO=https://github.com/NASA/ogma" -e "NAME=ogma" -e "BASE_COMMIT=02e2a4c1439279b700699923c351dac39527e2b5" -e "COMMIT=<HASH>" -it ogma-verify-244
```

**Solution implemented**

Modify ROS backend to leverage `aeson` capabilities to make a data
structure available to the ROS template, and move as much as possible of
the current logic in the ROS backend directly to the template.

**Further notes**

This situation also affects other backends. We limit this issue to the
ROS backend to make the work smaller, easier to complete, and to reduce
risk.

Author: ivanperez-keera

ogma-cli/CHANGELOG.md

@@ -1,6 +1,6 @@
 # Revision history for ogma-cli
 
-## [1.X.Y] - 2025-02-04
+## [1.X.Y] - 2025-02-07
 
 * Add all auxiliary test files to distributable Cabal package (#216).
 * Remove extraneous EOL character (#224).
@@ -10,6 +10,7 @@
 * Expose template-vars argument to cFS backend (#106).
 * Document new template variables in README (#237).
 * Fix formatting of template variables in README (#222).
+* Update README with new ROS template variables (#244).
 
 ## [1.6.0] - 2025-01-21
 

ogma-cli/README.md

@@ -355,50 +355,17 @@ Ogma will copy the files in that directory to the target path, filling in
 several holes with specific information. For the monitoring node, the variables
 are:
 
-- `{{variablesS}}`: this will be replaced by a list of variable declarations,
-  one for each global variable that holds information read from the ROS
-software bus that must be made accessible to the monitoring code.
-
-- `{{msgSubscriptionsS}}`: this will be replaced by a list of calls to
-  `create_subscription`, subscribing to the necessary information coming in the
-software bus.
-
-- `{{msgPublisherS}}`: this will be replaced by a list of calls to
-  `create_publisher`, to create topics to report property violations on the
-software bus.
-
-- `{{msgHandlerInClassS}}`: this will be replaced by the functions that will be
-  called to report a property violation via one of the property violation
-topics (publishers).
-
-- `{{msgCallbacks}}`: this will be replaced by function definitions of the
-  functions that will be called to actually update the variables with
-information coming from the software bus, and re-evaluate the monitors.
-
-- `{{msgSubscriptionDeclrs}}`: this will be replaced by declarations of
-  subscriptions used in `{{msgSubscriptionsS}}`.
-
-- `{{msgPublisherDeclrs}}`: this will be replaced by declarations of publishers
-  used in `{{msgPublishersS}}`.
-
-- `{{msgHandlerGlobalS}}`: this will be replaced by top-level functions that
-  call the handlers from the single monitoring class instance (singleton).
-
-Ogma will also generate a logging node that can be used for debugging purposes,
-to print property violations to a log. This second node listens to the messages
-published by the monitoring node in the software bus. For that node, the
-variables used are:
-
-- `{{logMsgSubscriptionsS}}`: this will be replaced by a list of calls to
-  `create_subscription`, subscribing to the necessary information coming in the
-software bus.
-
-- `{{logMsgCallbacks}}`: this will be replaced by function definitions of the
-  functions called to report the violations in the log. These functions are
-used as handlers to incoming messages in the subscriptions.
-
-- `{{logMsgSubscriptionDeclrs}}`: this will be replaced by declarations of
-  subscriptions used in `{{logMsgSubscriptionsS}}`.
+- `{{variables}}`: list of variable declarations, one for each external data
+  source needed to be read from the ROS software bus and made accessible to the
+  monitoring code. For each variable declaration, the fields defined are:
+  - `{{varDeclName}}`: name of the variable.
+  - `{{varDeclType}}`: raw type of the variable.
+  - `{{varDeclId}}`: topic name from which this variable can be obtained.
+  - `{{varDeclMsgType}}`: type used to pack this variable in the software bus.
+
+- `{{monitors}}`: list of monitors or error handlers, which will be used by the
+  monitoring application to notify of faults or updates from the monitoring
+  system.
 
 We understand that this level of customization may be insufficient for your
 application. If that is the case, feel free to reach out to our team to discuss

ogma-core/CHANGELOG.md

@@ -1,6 +1,6 @@
 # Revision history for ogma-core
 
-## [1.X.Y] - 2025-02-06
+## [1.X.Y] - 2025-02-07
 
 * Import liftIO from Control.Monad.IO.Class (#215).
 * Remove references to old design of Ogma from hlint files (#220).
@@ -14,6 +14,7 @@
 * Remove dependency on ICAROUS from generated cFS applications (#237).
 * Remove incorrect function declaration from template (#240).
 * Re-structure cFS backend to avoid nested conditions (#242).
+* Make structured data available to ROS template (#244).
 
 ## [1.6.0] - 2025-01-21