Skip to content

Ecosystem Review

Introduction

The Ecosystem review process serves as the pathway to getting your device approved and published on the marketplace and Industrial Edge Hub. Our team conducts a thorough evaluation of your device, applying our Ecosystem framework, quality checks, and security assessments to ensure it meets our standards for proven quality. Once your device successfully passes the review, it will enter the publicity state, granting approval for marketplace release and visibility to others. We recognize the importance of this step for you as a device builder and strive to make the process transparent and efficient. This document provides an overview of the quality test process, input conditions, and technical test cases involved in the Ecosystem review, empowering you to enhance your device's readiness to meet the needs of our Industrial Edge users. Thank you for choosing to submit your device for the Ecosystem review process; we are excited to collaborate with you and support your success in the marketplace.

Why Ecosystem review?

Siemens Ecosystem team is conducting a thorough review of the ecosystem to ensure that the device aligns with the framework. In addition, the Ecosystem team is implementing quality assurance measures that include upfront test standards based on common pitfalls, which will help us reduce time to market. Our focus on security involves conducting thorough security checks to minimize risks for our customers.

Scalability is also a crucial aspect as we strive to enhance trust in the device's quality, enabling us to sell it on a large scale. Lastly, we aim to increase trustworthiness by implementing a standardized onboarding process, which will improve the reliability of the device.

By prioritizing these key areas, we can ensure that your device meets the needs of our customers, delivers high-quality user experiences, and can be confidently sold at scale.

Prerequisites

  • Integration of IEDK packages is completed (→ your product is in the state of a "release candidate")
  • IEDK Test Suite results available and showing zero (0) errors
  • Artifacts are available
    • Device type
    • Firmware
    • Release notes
    • Documentation with relevant information for test team
    • Specification sheet

Ecosystem review process

  1. Initial Phase
  2. Usability Tests
  3. Configuration Tests
  4. App feature Tests
  5. Security Tests
  6. Result Phase

1. Initial Phase

In the initial phase all the groundwork for a successful test needs to be done. In this phase all the information and files required for the actual execution of the later tests are collected. In order to be published on the marketplace, it is necessary to provide all the information requested.

Get in contact with your Ecosystem Manager inbox to inform about the start of Ecosystem review process. For the review to start please send the required files and documents to your Ecosystem manager.

1.1 IEDK Test Suite results are provided

Test Title IEDK Test Suite results available
Test Category Mandatory before testing
Description To verify the successful integration the test results performed by the Device Builder must be sent to the Ecosystem team.
Exception Condition If it is a initial release the device can be provided including the firmware (OS + EdgeIoTCore + services)
Failed condition No test results available or test showing >=0 errors. No further testing is performed.

1.2 Device release candidate hardware is provided

Test Title Device hardware is available
Test Category Mandatory before testing for hardware-based devices
Description In order for us to begin our review process, the Device Builder must provide one physical hardware device that has integrated IEDK and services running.
Exception Condition For software-based devices this test case is not neccessary
Failed condition No hardware available. No further testing is performed.

1.3 Device type file .json is provided

Test Title Device type file .json available
Test Category Mandatory before testing
Description To create the device type in the testing environment the Device Builder must send the created device type to the Ecosystem team
Exception Condition -
Failed condition No device type available. No further testing is performed.

1.4 Firmware artifacts are provided

Test Title Firmware available
Test Category Mandatory before testing
Description To upload the firmware to the created in 1.2 in the testing environment the Device Builder must send the firmware to the Ecosystem team
Exception Condition If it is a initial release the device can be provided including the firmware (OS + EdgeIoTCore + services)
Failed condition No firmware available. No further testing is performed.

1.5 Release notes are provided

Test Title Release notes .md file available
Test Category Optional before testing
Description To upload the release notes to the public documentation the Device Builder can already send a version of the release notes .md file.
Exception Condition -
Failed condition No release notes available. Further testing is performed.

1.6 Documentation is provided

Test Title Documentation available
Test Category Optional before testing
Description To enable the test team to perform the test any specific information can be sent in a documentation about the device. E.g. creadentials, IP configuration etc.
Exception Condition -
Failed condition No documentation available. Further testing is performed.

1.7 Device specification sheet is provided

Test Title Specification available
Test Category Optional before testing
Description To gain insights in the device functionality, resources and other specification
Exception Condition -
Failed condition No specification sheet available. Further testing is performed.

2. Usability Tests

Usability test cover the way of how a Industrial Edge user would work with the Industrial Edge device and Industrial Edge Management features concerning devices.

2.1 IEM to IED Forward

Test Title IEM to IED Forward
Test Category Mandatory
Description When clicking on the Device IP Link in the IEM View, you do get redirected to the Device's Edge UI.
Exception Condition -
Failed condition Not forwarded to IED UI. No further testing is performed.

2.2 Log Download

Test Title Log Download
Test Category Mandatory
Description Device Logs & Application Logs can be downloaded trough the Device-UI.
Exception Condition -
Failed condition No download or no logs available. No further testing is performed.

2.3 Onboard / Remove

Test Title Onboard / Remove
Test Category Mandatory
Description Device can be sucessfuly onboarded with the correct Device type. Device can be "removed" from the IEM and the device is not getting reseted.
Exception Condition -
Failed condition Not onboarding or not removing. No further testing is performed.

2.4 App Installation / Update / Uninstallation

Test Title App Installation / Update / Uninstallation
Test Category Mandatory
Description Applications can be installed, updated and uninstalled to/from the device and no configuration/volume is left over.
Exception Condition -
Failed condition Apps do not install/update/uninstall. No further testing is performed.

2.5 Login federation

Test Title Login federation
Test Category Mandatory
Description Application could use IDE users to Authenticate (e.g Flow Creator, amiedgy).
Exception Condition -
Failed condition Not possible to use IED user to log in to app. No further testing is performed.

2.6 Reset / Hard Reset

Test Title Reset / Hard Reset
Test Category Mandatory
Description Reset: The Device has applications installed and after a Reset, only the Application and it's volumes are gone. Hard Reset: The Device has applications installed and after the Hard Reset all Applications, it's volumes and the device configuration is gone. The Device is offboarded of the IEM. The Network settings can stay persistent.
Exception Condition -
Failed condition Reset / Hard reset not possible. No further testing is performed.

2.7 Remote Access trough IEM

Test Title Remote Access trough IEM
Test Category Mandatory
Description Remote Access can be activated for the device, connected to the device and applications can be accessed trough the remote access of the IEM.
Exception Condition -
Failed condition Remote Access cannot be activated. No further testing is performed.

2.8 Developer Mode

Test Title Developer Mode
Test Category Mandatory
Description Developer mode can be enabled and disabled and used as intended.
Exception Condition -
Failed condition Developer mode cannot be enabled. No further testing is performed.

2.9 Registered Ports

Test Title Registered Ports
Test Category Mandatory
Description All ports that applications are exposing need to be listed in the "Registered Ports" tab of the Device.
Exception Condition -
Failed condition Ports not or not correctly listed in "Registered Ports". No further testing is performed.

3. Configuration Tests

Configuration tests cover whether on the IED all required capabilities can be configured.

3.1 NTP Server

Test Title NTP Server
Test Category Mandatory
Description NTP Server can be set, unset and modified during runtime. Time will be syncronised with NTP-Server.
Exception Condition -
Failed condition NTP Server can not be configured or no time synchronization. No further testing is performed.

3.2 Proxy

Test Title Proxy
Test Category Mandatory
Description A Proxy can be configured.
Exception Condition -
Failed condition A proxy can not be configured. No further testing is performed.

3.3 Network Settings

Test Title Network Settings
Test Category Mandatory
Description The Interface of the device can be modified (DHCP/Static/Gateway/DNS-Server/...)
Exception Condition -
Failed condition Network interface can not be modified. No further testing is performed.

3.4 Logging & Monitoring

Test Title Logging & Monitoring
Test Category Mandatory
Description The Logging & Monitoring feature of IEDK can be configured and used.
Exception Condition -
Failed condition The Logging & Monitoring feature of IEDK can not be configured and used. No further testing is performed.

3.5 Certificate Handling

Test Title Certificate Handling
Test Category Mandatory
Description New IEM Cerificates can be imported to the deivce and the device will use them from now on.
Exception Condition -
Failed condition Errors during IEM Certificate handling. No further testing is performed.

3.6 Timeout Alerts

Test Title Timeout Alerts
Test Category Mandatory
Description Timeout and alerts can be set.
Exception Condition -
Failed condition Timeout and alerts can not be set. No further testing is performed.

4. App feature Tests

App feature tests cover the required device capabilities regarding apps to be configured.

4.1 Event Service

Test Title Event Service
Test Category Mandatory
Description Event Service can be configured.
Exception Condition -
Failed condition Event Service can not be configured. No further testing is performed.

4.2 Device Module

Test Title Device Module
Test Category Mandatory
Description Device Module can be configured.
Exception Condition -
Failed condition Device Module can not be configured. No further testing is performed.

4.3 Layer 2

Test Title Layer 2
Test Category Mandatory
Description Layer 2 can be configured.
Exception Condition -
Failed condition Layer 2 can not be configured. No further testing is performed.

5. Security Tests

Network Segmentation
Prohibit general routing or bridging between connected networks by default. It can be possible to adjust the routing via a configuration mechanism or installing specific apps if metrics on routes or individual routes mustbe set.

Hard Reset
Whenever the hard reset is triggered, it must be ensured that all security-relevant information e.g., passwords are securely deleted from the device.

Time Synchronization
It is necessary to provide an up-to-date time on the device. NTP compatible protocols, like NTPsec.

Storage of Artificats
It must be ensured that all directories, which contain IE packages and the corresponding volumes to store app data are protected against read access and modification.

Secure Logging
Devices must emit logs via an API to be able to export them on IEM e.g., for auditing or operational purposes.

Trusted Deployment Of Updates
Devices must implement a trusted deployment of updates to ensure the integrity of update packages.

Authentication
If a user needs access to an Edge Device for administration or configuration purposes the access needs to be secured by a login mechanism with state-of-the-art credential policies.

Root Privileges / Runtime Protection
Based on the user roles, authentication must be enforced. Root-privileges are prohibited on productive devices. Only the Device Builder is allowed to have a root-access for debugging of the firmware.

Recovery option
It is required to ensure a method that the user can reset the device if e.g. the admin credentials have been lost.

6. Result phase

If the tests failed in any of the test stages, the tester will inform the Ecosystem team to get in contact with the device builder. EOM Manager will inform the Device Builder about the failure causes and comments from the test team.