ogma-cli: Update README.

ogma-cli/README.md

@@ -256,9 +256,16 @@ the processing to an auxiliary function.
   they carry, and their names. For each item, a `{{msgDataDesc}}`,
 `{{msgDataVarName}}` and a `{{msgDataVarType}}` are defined.
 
-- `{{triggers}}`: list of error handlers or fault triggers, which will be used
-  by the monitoring application to notify of faults or updates from the
-  monitoring system.
+- `{{triggers}}`: list of monitors or fault triggers, which will be used by the
+  monitoring application to notify of faults or updates from the monitoring
+  system. For each monitor or trigger, the fields defined are:
+  - `{{triggerName}}`: name of the monitor.
+  - `{{triggerType}}`: type of the argument received by the monitor, if any.
+    This allows monitors to communicate additional data, or to use monitors for
+    data processing by making the monitor condition always true and passing a
+    result as an argument.
+  - `{{triggerMsgType}}`: corresponding type of cFS message to communicate the
+    additional data as a result, if any.
 
 Additionally, the `cfs` command accepts a file with a JSON object listing
 additional variables to be expanded in the template. To make use of this
@@ -432,7 +439,14 @@ are:
 
 - `{{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.
+  system. For each monitor, the fields defined are:
+  - `{{monitorName}}`: name of the monitor.
+  - `{{monitorType}}`: type of the argument received by the monitor, if any.
+    This allows monitors to communicate additional data, or to use monitors for
+    data processing by making the monitor condition always true and passing a
+    result as an argument.
+  - `{{monitorMsgType}}`: corresponding type of ROS message to communicate the
+    additional data as a result, if any.
 
 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
@@ -444,9 +458,6 @@ The user must place the code generated by Copilot monitors in two files,
 `ros_demo/src/monitor.h` and `ros_demo/src/monitor.c`. No Copilot or C code for
 the monitors is generated by default.
 
-The code generated by default assumes that handlers receive no arguments. The
-user must modify the handlers accordingly if that is not the case.
-
 Although the variable DB file is not mandatory, it is in practice required to
 monitor any requirement that uses any input data: no topic subscriptions will
 be generated for any variables for which a DB entry cannot be found. At present,
@@ -577,6 +588,12 @@ variables available are:
   system. For each monitor, the fields defined are:
   - `{{monitorName}}`: name of the monitor.
   - `{{monitorUC}}`: name of the monitor, in capital letters.
+  - `{{monitorType}}`: type of the argument received by the monitor, if any.
+    This allows monitors to communicate additional data, or to use monitors for
+    data processing by making the monitor condition always true and passing a
+    result as an argument.
+  - `{{monitorPortType}}`: corresponding type of port for the argument received
+    by the error handler, if any.
 
 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
@@ -589,9 +606,6 @@ The user must place the code generated by Copilot monitors in three files,
 `fprime_demo/src/copilot.c`. No Copilot or C code for the monitors is generated
 by default by the `fprime` command.
 
-The code generated by default assumes that handlers receive no arguments. The
-user must modify the handlers accordingly if that is not the case.
-
 ## Generating Monitors from Diagrams
 
 Apart from the backends mentioned before, Ogma includes a command to