Firmware Generation Status Definition and Versioning Scheme

Hilscher offers a wide range of protocol firmware variants for netX SoC based products. We may maintain and offer more than one generation of a specific protocol firmware variant at the same time. For example, up to three different PROFINET firmware generations are available, which meet latest conformity requirements. Nevertheless, firmwares pass through a life cycle, from brand new release over maturity to end of life. This document explains the Hilscher protocol firmware versioning scheme, defined firmware status and guaranteed maintenance time periods.
Firmware users can derive what versions are recommended for new designs and how long particular versions are maintained.

Firmware Generation Status

A particular firmware file/package belongs to a firmware generation, defined by the major version digit.
For example, V5.1.0.0 is a release version, belonging to generation 5.

Each Firmware generation has a firmware status, which reflects the position in life cycle.

The firmware status is subject to change.

Hilscher recommends using firmware in status “active” for new designs, based on the latest technologies. Firmware in status “active” guarantees full performance and greatest set of features.

Firmware Generation StatusDescriptionUsage in products

ACTIVELATEST

latest recommended firmware generation, latest technology
maintained and enhanced by new features

meet latest certification requirements

design-in and product updates

ACTIVE

actively maintained and enhanced by new features
meet latest certification requirements

newer product exists, add value by migration to latest technology

LIMITED

not recommended for new designs,
migration to new technology recommended

bug fixing only, no new features anymore

meet latest certification requirements

production only

OBSOLETE

No development anymore

severe bug fixing only

successful certification not guaranteed

figure: firmware life cycle

Firmware Status Transitions

Hilscher announces firmware end of life, i.e. the status transition to “obsolete”, minimum 12 month in advance. Other status transitions have no deadlines.

Transition

Note

Deadlines

Announcement

Pre-Development
->
Active/Latest


Pre-releases may become available about 3 month prior to the official firmware release

Webpage, public blog, press release

Active Latest
->
Active

When brand new technology becomes available, "active latest" firmware might loose its "latest" status
"active" firmware is still fully maintained and enhanced by new features

None

Webpage, public blog

Active
->
Limited

Typically migration to a new technology is already established, before status changes to limited,

Migration to new technology recommended

None

Transition to “limited” might be performed when EOL is announced

Webpage, public blog

Limited
->
Obsolete

Obsolete firmware can still be used in production,

due to grace periods, device certification is still possible for a certain time after end of life

Announcement >=12 month prior to status transition to “obsolete”

Dedicated EOL information to each user,
Webpage, public blog


Versioning Scheme

A particular firmware file/package belongs to one, out of three possible, version-types:

TypeLabelDescription
Release Version

RELEASE

Software revision with new features
API may differ in relation to other release versions
Hotfix Version

HOTFIX

Bugfixing only, no new features

same API and same feature set as related release version

Pre-Release Version

PRE-RELEASE

Firmware version for evaluation purposes only

The version type is not a subject to change, in contrast to the status of the firmware generation. A release version, e.g. PROFINET firmware V5.2.0.0, remains a release version, independent of the status of the respective firmware generation.


Each protocol firmware has a 4 digit version number. A dot “.” separates each digit.

Digit

Meaning

Description

A

Major

firmware generation

Major differences to other firmware generations

B

Minor

firmware revision

API may differ in relation to other minor revisions

C

Pre-Release

firmware version for evaluation purposes only

Pre-Releases have a C-digit unequal to 0

C is always 0 in official revisions for mass production

D

Hotfix

Bugfixing, no new features

same API and same feature set, as versions with same major and minor revision


Examples

V 5.2.0.0        release version (new features and different API compared to V5.1.0.x)

V 5.2.0.7        hotfix version of V5.2 (bugfixing only, same features and same API as V5.2.0.x)

V 5.2.1.0        pre-release of upcoming V5.3.0.0 (new features and different API compared to V5.2.0.x) for development purposes only

Major Digit

The major version number defines a firmware generation. Generations differ in SW architecture, feature set and availability for particular target devices. Firmware generations are developed maintained and offered over a long time period of several years. The APIs of different firmware generations are not compatible and might differ significantly. User applications might require adoptions if the used firmware generation is changed.

Minor Digit

The minor version number defines firmware revisions. In the course of the firmware development, Hilscher implements new features and assures conformity to new certification requirements (guarantee successful conformity tests). New revisions are typically released in time periods of several month to once per year. The APIs of different firmware revisions (from the same firmware generation) are very similar, though Hilscher does not guarantee compatibility . In many cases, only new services are extended which may be optionally used in an application. Usually, only minor modification to the user application must be implemented.

Hotfix Digit

Hotfix versions are typically published only for bug-fix purposes, not for release of new features and functionality. The API of hotfix versions is not changed, compared to other versions of the same major.minor version firmware. It is not necessary to adapt the user application if a hotfix version is applied.

Pre-Release Digit

Pre-Release firmware is provided only on request to allow early integration and customer feedback, they are not published officially. Pre-release firmware is intended for development purposes only. It must not be used in mass production.


Maintenance Time Period

Maintained firmware is supplied with bugfixes and conformance related improvements by Hilscher in the form of "Hotfix Versions". The latest revision version of a firmware is always maintained by Hilscher.

If a firmware is replaced by a newer revision, Hilscher guarantees a maintenance time period of 12 month for the previous, replaced firmware revision. 12 month after release of a new revision, maintenance for the previous revision is ultimately ceased. Referring to the figure below, at release of Firmware revision V5.2.0.0 (blue bars) the 12month maintenance period for Firmware revision V5.1.0.0 (red bars) is started. New hotfix versions for V5.1.0.x will be published only until the 12 month maintenance period is expired. I.e. V5.1.0.4 would be the last hotfix version of revision V5.1.0.x. If bugs are discovered after the 12 month maintenance period, these are not fixed in V5.1.0.x anymore, but only in the successor revisions V5.2.0.x and/or V5.3.0.x, etc.

(warning) A firmware revision with expired maintenance (no hotfixes offered anymore) is labeld with EXPIRED

Maintenance StatusLabelDescription
within maintenance time period (minimum 12month)
MAINTAINED
hot fix versions for an older firmware revision are offered
maintenance time period is expired

EXPIRED

no hotfix versions are offered anymore for an older firmware revision
A firmware revision must be replaced by a newer revision

API may differ in relation to other release versions


figure: development thread