8.Generate Services

Before discussing Service Generator, please note that a service can derive from other service. The derived service inherits the states and transitions of the base service, but it can override the state handling functions, transition functions, input message and internal events handling functions of the base service.

The common examples of the service inheritance is that a safety critical service derived from core.Management service so that it could implement handling of the Emergency condition.

We will show examples that services are not derived and derived from other service.

The Service Generator generates .h and .cpp files of the service. For Example: uli_sdk/services/experimental/json/pose_driver.json generates following files:

　　pose_driver.h and

　　pose_driver.cpp files.

8.1.1　JSON

Refer to Appendix A, Service Generator, Not Derived, JSON Example and Service Generator, Derived, JSON Example. More examples can be found in uli_sdk/services/core/jsons and uli_sdk/services/mobility/jsons.

Here are the explanations:

• fullname – the class name of the service, including the full name spaces. The name is in camel style, the first letter is in upper case.
  
• override – the class name of the base service to derive from, including the full name spaces. The name is in camel style, the first letter is in upper case
• uuri – the uri of the service. The format should be .. For example: “core.MessageTransport”.
• majorversion – the major version number of the service.
• minorversion – the minor version number of the service.
• overridable – whether the service can be derived by other service. Value should be either “yes” or “no”.
• params – array of the configurable parameters of the service. The parameter name is in camel style, the first letter is in lower case.
• states – array of the states of the service. The state name is in camel style, the first letter is in upper case.
• transitions – array of the transitions of the service. The name is in the format 2. The transitions generate transition functions called during state transition. The transition function has return type of bool. Transition does not occur if the transition function returns false.
• inputs – array of the class names of the input messages. The class names include full name spaces and in camel style, the first letter is in upper case.
• outputs – array of the class names of the output messages. The class names include full name spaces and in camel style, the first letter is in upper case.
• subscriptables – array of the class names of the report messages that can be subscribed via the Subscribe service. The class names include full name spaces and in camel style, the first letter is in upper case.
• overrideinputs – array of the class names of the input messages of the base service that this service overrides their handler functions.
  
• ies – array of class names of the internal events the service is to handle. The name includes full name spaces.
• overrideies – array of class names of the internal events of the base service that the service is to override their handler functions.
• raiseies – array of class names of the internal events the service is to raise. The name include full name spaces.

In Appendix A, Service Generator, Derived, JSON Example shows the PrimitiveDriver service JSON file.

The PrimitiveDriver service is derived from core.Management. The core.Management service manages the life cycle of the service, including states for handling emergency. Refer to core_services document for details description of the Management service.

The PrimitiveDriver service is to override the state and transition handler functions of the core.Management service.

The PrimitiveDriver does not override inputs to the core.Management service. The overrideinputs is left empty. However, it has its own input messages: MobilitySetWrehcnEfforts and MobilityQueryWrenchEfforts.

The PrimitiveDriver does not have internal events need to handle, but it overrides ieReceiveMessage handler function. See overrideies in the JSON.

You should compare the Management.json in the uli_sdk/services/core/jsons.

8.1.2　Important Notes

Service generator generates codes in code_gen/services directory. You need to copy the codes to proper directory, for example: the generated experimental_pose_drive codes are copied to uli_sdk/services/experimental/.

Service generator does not create BUILD file for building the generated service codes. You need to add the BUILD file to the directory where the generated service codes are copied to. Or insert the proper entries to the BUILD file if the BUILD already exists.

Refer to Appendix A, Service Generator BUILD File Example.