Application Management

Application management is the process of deploying, activating, deactivating, and decommissioning applications in the GEISA execution environment. Please see notes from the Technical Deep dive for additional notes / context.

Note: Application Monitoring is treated as a separate topic.

Application Metadata

GEISA’s application management system will follow a model similar to Amazon IoT Greengrass or Microsoft Azure IoT in which applications have a recipe, manifest, or other set of meta-data describing their requirements and dependencies.

The application meta-data shall include:

• Name, Description, and Version of the application

• Hash of the application image

  • The GEISA application execution environment shall not activate an application unless the hash of the image matches the hash in the meta-data

• System Resources required

• External Dependencies

  • GEISA applications should be as self-contained as possible, with all necessary dependencies contained within the application image if at all possible.

• Application Boot Configuration

  • Some applications will need basic information to initialize, such as the URL of a server. The system operator should be able to change the boot configuration information without needing to redeploy the application image.

• Launch Strategy

  • Includes details such whether the application should automatically be restarted if it fails, and how many failure within a given period of time constitutes a permanent failure.

Application Management Protocol

GEISA needs to select a specific application management protocol to enable interoperability. Given the scale of GEISA (millions of devices), it is critical that the protocol be as light-weight as possible. ReSTful architectures are proven to scale very well, and thus are a preferred starting point. GEISA is currently exploring several possible management protocols, including:

• OMA Specworks LWM2M

• CoAp Simple Management Protocol (CSMP)

• Welotec SMART EMS

Both LWM2M & CSMP are ReSTful in nature. LWM2M originated with CoAp and has been expanded to other protocols including HTTP and MQTT. CSMP is CoAp only.

The team also discussed the potential of using Mender. Mender appears to provide a robust over-the-air firmware update and application update solution, but not a more general management solution.

Comparison Table

Deploying

Activating

Deactivating

Decommissioning

Management Agent

Discussion Notes from 2025/2/18 working session

Could we choose not to specify a protocol, but instead specify the requirements for an agent and requirements for agent features?

The challenge with this approach is that it limits practical interoperability for the end user. If device X uses protocol 1, and device Y uses protocol 2, how are they managed? Does the management speak both protocols? Does the end user have to have one management system for each device type?

Could we have a manager of manager approaches? This isn’t preferred from a utility standpoint, as it still results in having multiple head-end management systems.

One concern is whether device vendors would still need a second protocol to address device unique concerns. Extensibility might address this. Generally, the management protocol must be extensible to allow additional actions and management of vendor specific elements. The management system (which is out of scope for GEISA) will need to support the vendor specific elements. From an interoperability standpoint, this means end users will need to purchase an extensible management system if they want to deploy devices from multiple vendors which each require their own custom objects.

Ideally, GEISA would provide sufficient capabilities that the need for custom objects is minimal.

How will the management system be bootstrapped?

Devices are likely to have dynamic addresses. Unless the management system has some sort of direct link to the address provisioning system (unlikely, especially in public carrier environments), the devices will need to register with the management system. How does the device know where the management system is?

• Preinstall

  • Device is programmed with the address at the factory, at the staging depot, or in the field at time of deployment.

• Minimal bootstrapping process

  • Device obtains management details through network security registration

• DHCP vendor option

  • GEISA uses specific vendor option code to obtain management system address; end user must be able to set DHCP server option

• DNS

  • Device obtains DNS servers as part of DHCP

  • Device resolves well known management server name (e.g. geisa-management.domainname.domainsuffix)

Note: while any of these are potentially subject to spoofing, mutual authentication using certificates can address this concern; however, that will require preinstalling certificates, or having a common root certificate or both.