Skip to content

Developing Apps

App Developer Approval

To qualify as an Industrial Edge app partner, the following criteria have to be fulfilled as a pre-condition for publishing applications on the Ecosystem.

  • Explicit end user need for the app as well as use cases
  • Domain expertise in a specific industry
  • Regional market expertise (for example, app provider from Europe for Europe)
  • High maturity state of the app and/or compliance with Docker architecture
  • Ease of use for end user (self-service app vs. configuration services)
  • Willingness to pilot, incubate, and familiarize oneself with the Ecosystem Cornerstones
  • Available resources that cover all product lifecycle stages (for example, pre-sales or service phase)
  • App was tested and reviewed by Industrial Edge Test Center (App Testing and App Review)
  • Successful technical (App Review) and commercial product onboarding (Product Onboarding Criteria)
  • Compliance with and signed Marketplace Seller Agreement and Ecosystem Agreement
  • Compliance with supported business models (App Types and Licenses)
  • Accepted Marketplace listing and services (commission on app sales and membership fee)

App providers who fulfill all affiliation criteria are granted the right to publish their apps on the Industrial Edge Hub and Industrial Edge Marketplace.

Software Design Regulations

Software design regulations can never be completely specified, because there are too many variations in how technical challenges can be solved. Therefore, the following is a description of the minimum requirements for successful app development.

Containerization

All apps must be encapsulated in one or more containers. These containers must be based on the Open Container Initiative (OCI) image specification and be compatible with Docker implementation.

An app is defined as a bundle of such containers that are orchestrated and configured via a Docker Compose file.

Versioning

All componets, apps, software ware producst and documents are versionised. This versioning have to follow the semantic versioning 2.0.

Hardware-agnostic

If possible, apps must be designed to run on any hardware device. All components must be designed to run on an x86‑64 or arm64 architecture: for example, the Siemens IPC227E.

Communication

The standard for communication is the IP based network and protocols like http, https, MQTT, and corresponding ports. Every service has a URL address. Inter-app communication occurs via the Databus and additionaly via Point-to-Point communication as an option. Interfaces to the Databus must be designed according to its Common Payload specification. Interfaces for the Point-to-Point communication must be documented and published together with the Siemens Industrial Edge Ecosystem-Team (e.g. Vision Payload specification).

Processes

Apps are designed based on the "share nothing" principle, with services that act independently of each other.

Whenever possible, platform services must be used for shared resources. Deviations from this standard are the responsibility of the app provider.

Concurrency

The concurrent use of resources from different apps must be enabled on one device without blocking resources.

Focus on App Strengths

Every application has a defined purpose and function.

This makes it possible to combine apps from different parties to create solutions for specific end user needs, instead of creating monolithic systems.

Self-containing

Apps must contain everything they need to provide their services.

This implies that individual services need to run without mandatory dependencies on other applications.

The value of Industrial Edge lies in a dynamic combination and extension of offerings based on end user needs for specific solutions.

Awareness of other application

Due to technical restrictions of the Industrial Edge software, some configurations of an application need to be unique upon all applications that are present in the marketplace.

These are "Repository-Name", "service names" and "App specific URL subdirectory path".

Not following these rulesets could case users to experience an unwanted behavior of purchasing two applications and not being able to run both at the same time on one device.

The only exception to this would be: The same "service names" or "App specific URL subdirectory path" are knowingly provided by one application provider with the intention of preventing these applications from running at the same time on the same device.

Caching

Apps should provide sufficient caching strategies so that resources from app-external components are used reliably and economically.

Availability

Providers should focus their app development on robustness with a fast startup and smooth shutdown of all app components.

Ideally, an app should start within seconds.

Logs

Apps must provide log information about their work and state changes. Apps log this information via the "standard out" of their containers. This information is handled by edge devices and enriched with meta information.

If an app provider decides to define their own logfiles without streaming it through std out, it must contain all parts of a common log format.

A common log format consists of a plain text file that’s named app name and the file extension is .log. For multi-container applications, the container name should also be added.

The file needs to be stored to the standard volume for logs. Within the file, each logging event is written as one line and should adhere to the following structure:

  • Timestamp
  • Level of message
  • Emergency
  • Alert
  • Critical
  • Error
  • Warning
  • Notice
  • Information
  • Debug
  • App name (+ container name)
  • Message text

Prevent Disruptions

Robustness on industrial products has a high priority.

Components must be designed to handle errors with as little disturbance as possible to other components.

Nevertheless, errors can occur. Therefore, apps need to be fault-tolerant in order to provide a smooth user experience and workflow.

User Interface

Industrial Edge is supported by a plurality of devices, display sizes, and resolutions in manufacturing.

Application providers need to consider this requirement in order to create a responsive Web design.

All application and device user interfaces must be Web-based. User interfaces should be accessible via the system provided reverse proxies.

Therefore, standard http behavior is required. To reach a wide range of potential end user, the application must be optimized for state-of-the-art browsers: for example, Chrome without plug-ins using HTML5 and related technologies.

The Siemens Industrial Experience is recommended in order to create a consistent user experience.

Integrating touch support for dedicated use cases is also recommended.

APIs

All APIs that are intended for public use need to be documented in the product’s Developer Documentation.

Internal APIs shouldn’t be accessible in order to minimize the risk of security attacks. Using the OpenAPI specification formerly known as Swagger is also recommended.

API specification must have a versioning to ensure backwards combability.

Data Exchange

All apps that are handling data streams should make exchanges accessible via the Industrial Edge data bus.

The Industrial Edge State Service is the Industrial Edge disaster recovery solution that backs up and restores your edge device’s states.

The Industrial Edge State Service supports the backup and restoring of app volumes of the following types: Host, Logs, Configs and Auth Service.

To secure an application’s data, the application’s volume types must be one of the types supported by the State Service.

Compatibility

An application must be compatible with the latest device and Industrial Edge Management version to ensure minimum compatibility.

Beyond the technical prerequisites, apps also need to deliver a certain level value, quality, and performance to end user, which is described in the next section.

End User Value Assurance

The Industrial Edge Ecosystem is focused on end user value and a seamless user journey for end user.

To achieve this, applications need to provide a minimum functionality, they need to be sufficiently tested by their development team, and they need to have collected and integrated feedback from real-world application scenarios before they’re published to the Hub.

Minimum Functionality

Apps should deliver a minimum functionality. App must provide value for end user or support them in accomplishing their tasks. To validate an app’s minimum functionality, the Marketplace entry will be checked to determine the application’s potential usage scenarios and to find out if there are alternatives for the end user to use to solve their task without using the app in question.

Apps that don’t provide a minimum functionality may not be accepted.

Core Functionality

The core functionality of each app needs to operate on its own without requiring the end user to install prerequisite apps that aren’t clearly specified.

Executable Applications

Applications created only for runtime purposes may subsequently load executable code. All other applications are prohibited from loading code and functionality after the initial installation.

Limit Authorizations

Apps can only request authorizations are necessary for providing their described functionality.

An app’s required access rights need to be described in the Marketplace entry.

Extracting Offerings

Apps that monetize primary based on other ecosystems aren’t allowed in the Ecosystem.

Apps that focus primarily on the extraction of production or end user data to other ecosystems without delivering value for the Ecosystem aren’t allowed in the Ecosystem.

Spoiling Apps

Apps that disturb hardware, networks, Industrial Edge infrastructure, or other third-party apps aren’t allowed in the Ecosystem.

Deceptive Apps

Apps that are intended to trick end user or enable illegal unfair activities for end user or the Ecosystem aren’t allowed in the Ecosystem..

Infective Apps

Apps that contain or support malicious behavior, viruses, malware, or phishing aren’t allowed in the Ecosystem.

Device-changing Apps

Apps that change the settings of devices are only allowed if the user is receiving informed about them, has agreed to this, and can undo the changes.

Ecosystem Inside the Ecosystem

Apps that create a nearly closed ecosystem inside the Ecosystem or build a bridge to other ecosystems aren’t allowed in the Ecosystem.

Copycats

The Industrial Edge Ecosystem protects their app providers’ intellectual property.

App providers are entitled to the rewards of their work and investments.

Therefore, each app provider should use their own ideas and not simply copy other app providers’ successful products (for example an app provider uses another app as a template and copies it).

If you find suspect apps, you can report them to the Ecosystem orchestrator

App Testing

App providers are responsible for developing, evaluating, and testing their apps in terms of technology, functionality, performance, security, and user interface.

They’re also responsible for establishing and maintaining the compatibility of their apps in the Industrial Edge environment (see also Ecosystem Agreement).

For X86-Architecture applications, a Siemens IPC227e running the current and previous runtime versions are used as a reference device to test and ensure the compatibility of apps.

For ARM64-Architecture applications, a Siemens SCALANCE LPE9413 running the current and previous runtime versions are used as a reference device to test and ensure the compatibility of apps.

After app providers successfully test their applications in-house, they need to send it to the Ecosystem Orchestrator for additional testing (App review).

The Industrial Edge Test Center will check user key workflows, compatibility, performance, and other factors. When a provider requests that their application be tested, a safe link is sent to them for uploading the app and other required documents (see App review ).

In addition to the testing responsibilities, a list of automated and manual verification steps is triggered when the app is sent to App Review.

If there are negative findings during the technical publication process at the Hub, the details will be provided to the app provider.

To ensure future a competability of your application with upcomming device versions, access to the Ecosystem-Prod environment should be requested and your application should be tested against the versions available on Ecosystem-Prod .

Initial versions and major-change versions have to be submited for Ecosystem Review. Additionaly random samples of all version might be taken for compliance check.

All issue(s) need to be resolved before re-submitting the application to the Test Center or App review.

App Prototyping

All applications submitted to the Industrial Edge Marketplace must be the final version for end user use. Therefore, providers need to ensure that it’s a sellable product. Demos, betas, and similar offerings don’t belong on the Industrial Edge Marketplace. App partners should test their apps in-house in the latest released edge environment to ensure the compatibility and functioning of their app before publishing it (see App testing).

App Review

Apps that are submitted for technical review on the Industrial Edge Hub must be the final version with all necessary information. Ensure that an app has been tested for compatibility and bugs before submitting it. Apps that crash or have obvious technical problems won’t be accepted.

During the technical review process, the following areas will be addressed:

  • Interaction between applications and Industrial Edge services
  • App file format and structure
  • Container state and health
  • Hardware demands
  • App security
  • Execution of individual process flow for every application
  • Application policies
  • etc.

The following needs to be provided for a successful technical review:

  • Application file in format “.app” (upload in Hub)
  • User manual (link to Web site)
  • Minimum hardware demand required for smooth operation (via Mail)
  • Public API specifications (link via Mail)
  • Description of core workflow of the application for testing purposes (via Mail)
  • etc.

The following needs to be provided for a successful onboarding on the marketplace:

  • Open-source software (OSS) file (upload in Hub)
  • Open-source software Readme.txt (upload in Hub)

Additional information that can’t be provided in the Hub should be sent to the Ecosystem Orchestrator. For more details see:

After a successful technical review, the app will be validated as a technically approved application. Because technology and business are always interacting, the following chapter explains the rights and responsibilities of app providers from a commercial perspective.

Because an app provider’s goal is to be onboarded on the Marketplace, the next section describes the deliverables required for a successful Marketplace listing.