System design file format

[isamu-takagi]

To make configuration more reusable and consistent, I would like to discuss the following suggestions:

Sections

Divide the config file into three main sections (+ others)

• interface section
• launch section
• process section

Interface section: This section covers the public interfaces common to nodes, modules, (and system).
Lists the external interfaces, whether they are implemented by nodes or modules. It consists of the following fields:

• topic-subscriptions (replaces node.input, module.external_interfaces.input)
• topic-publishers (replaces node.output, module.external_interfaces.output)
• service-servers (replaces node.input, module.external_interfaces.input)
• service-clients (replaces node.output, module.external_interfaces.output)
• parameter-values (replaces node.parameters, module.external_interfaces.parameters)
• parameter-files (replaces node.parameter-files)
• design-arguments (replaces system.modes, system.variables)

Launch section:

• instances (replaces node.launch, module.instances, system.components)
  • executable (<node>)
  • plugin (<composable_node>)
  • module (<include>)
  • command (<command>)
• connections
  • topics
  • services

[technolojin]

I think this is the last chance to revise the field names.

1. split service interface and connection: may necessary. but it could be distinguished with additional parameter in node interface. don't need to make it complicate. I do not prefer to add specific fields.
2. parameters are interface: agree. those are static interface
3. commonize field name between node, module, system: partially disagree. if the sub field requirement is different, it is better to have different name.

• system.component vs module.instance : system requires more (namespace, ecu...)
• node.input vs module.external_interface.input : only difference is message type(+ services field). suggestion: module.external_input
• node.launch vs module.instance : required fields are very different. user may confused. launch is clear meaning and

4. topic-subscriptions, topic-publishers: I feel your suggestions are too long. we uses those many times. I want to make those short and simple.
5. parameter-values: seems reasonable since we have parameter_files
6. module.external_interfaces.parameters : obsoleted
7. design-arguments : modes are very special. it need to be distinguished.

[isamu-takagi]

This is a summary of the results of the meeting with @technolojin.

• I wanted to treat node, module and system as a common entity as much as possible. However, the current Autoware design has many constraints, and unless these are resolved, standardization could lead to complexity. So I would like to make this a future challenge.
• The interface, launch, and process sections do not need to exist as actual fields. They are just for classification.
• The interface fields that start with topic, service, parameters seem fine except for the long name.
• The instances and components are almost the same, but we treat them as separate because we want the components to have special functionality.

[technolojin]

the format change has been partially implemented.
e9ee9ca

1. module.external_interface.input -> module.inputs (also for outputs)
2. version is incremented to 0.3.0

• adding explicit interface for services @isamu-takagi @mitsudome-r
  At this moment, server is located in 'outputs'. let me keep in the initial release and let us implement new type of interface later.

This concept works at this moment because the service is one-to-many communication. in ROS, topic pub-sub system enables many-to-many communication. However, in the Autoware system designer consider one-to-many as base (exception is global topics, such as /tf and /diagnostics)

[technolojin]

additionally renamed the keys about parameters #18

parameter_files -> param_files
parameters -> param_values

[technolojin]

clarification of service is implemented
#21

[technolojin]

the format update PR has been merged #26