Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Eclipse 4diac Wiki/4days Of 4diac/Deployment Session 2019

< Eclipse 4diac Wiki
Revision as of 10:08, 26 February 2020 by Alois.zoitl.gmx.at (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The session started with Jörg explaining the complete 4diac deployment process steps which included Code Export, installing tool-chain, download forte source, configure forte, copy forte to the target platform, export boot file to target platform, Run/Restart forte. It is a lengthy process and invites users to make mistakes such as installing wrong tool-chain, wrong configuration forte in CMAKE etc. Jörg suggested using OPC UA as a possible technology to improve deployment process with concerns about resource constraint devices. Also Devices should be able to handle update management like update failure, rollbacks, dynamic update.

During the meetings, two main questions were considered as major concerns:

  1. How do we update Run-time on a specific device?
  2. How and where to store the boot file on the specific platform?

Following approaches were discussed during the session:

  1. Run-time Directory for Forte:
  2. It holds the boot files, run-time, and security configuration files.

Step-Up CPS: Update Process:

Using containers image and the updated containers would take over the sessions of old containers.

OPC UA based update process:

OPC UA programs can provide a generic interface and the local methods can implement the device dependent options for update management. Kiril further added that state machines in OPC UA will allow us to control the deployment process so that no two users can update the boot file at the same time. OPC UA programs accept the full configuration (zip) as single download

  • Boot file
  • Forte Executable ( if the targets support run time updates)
  • OPC UA security configuration
  • executable plus zip files
  • Architecture Specific code manages, how to manage the update process,

Staging File/ Staging Update files:

Its a future update file, which is needed to configure run-time, after checking the systems.

Default Run-Time:

Systems can have default run-time if they have update process can leave out run-time.

Reboot based Update:

  • no live update/running system updates
  • REBOOT FB: knows that an update is pending and updates the devices when it is allowed. So it reboots and starts new forte. Update SIGNAL: From REBOOT FB going to the RESET /Kill the Resource.
  • E_RESTART: STOP signal triggered by OPC UA Program tell the application to STOP the application and update is pending, need to add STOP_CNF to let device know that it is to KILL device Now. Then STATE in OPC UA Programs recieves E_RDY status to continue the update process.
  • User access rights: These user access rights allows vendor and user to update the boot files, forte executable and other configuration based on the rights. These user access will be considered during the Activation of STATE and Triggering particular Transitions
  • Reject file: also checks the deployed Forte executable and devices performs the checks and tells that the current executable is not suitable for current device or not supported before starting Update process. The checks will defined by devices vendor or device dependent.
  • Eclipse Hawkbit: Back-end framework for rolling out software updates. Update Management tool.

Back to the top