What is the "application"?

Our platform is modular and scalable. That means you can combine right firmware with the right hardware to match your needs best. The application defines system-level behavior of the device.

Read more about firmware modules.

tip

• The application needs to be specified with the device order.
• The applications are hardware-independent to a certain level. This means you can scale your project and move between different device classes.
• Only our support team can change application as a part of after-sales process, if necessary.

We offer a range of off-the shelf applications, e.g. LYNX and OPHION for the controllers which are commonly used for sample evaluation and smaller scale series integration.

To meet the unique feature requests, we offer development of a custom application. This is a software (firmware) that runs on our devices and can be tailored to the customer's specific needs, can include custom features, branding, and more. The custom applications can be distributed across multiple devices in a single project and shelter the complete vehicle control. We call this also an OEM application.

Before starting such a development, we always encourage our customers to evaluate our products with our standard (public) applications. This will allow you to understand the capabilities of the device first and evaluate the features that are readily available off the shelf.

tip

• Check what is a SWID and what is the custom modification in the context of the SWID.
• Check what is an application in the context of device firmware.

Application types

warning

It is up to siliXcon developers to decide whether a new feature will be added to a public application, deployed within a custom modification or a new custom application right away. Usually, as the list of requested custom features expand, the conversion to a new custom application is necessary

Public application

By public, we mean that the application is available for everyone. The examples are LYNX and OPHION for the controllers.

tip

• Small customization suggestions are possible and welcomed. If siliXcon team decides, that the requested feature adds a global value, it can be added to the public application. In such a case, no opening fee is expected, and a new version will be automatically released.

Custom modification

Some feature requests are suitable for custom extension (modification) of a public application, but may not be candidates for generic inclusion. Reasons for this are usually the following:

• The new functionality is in conflict with the part of existing functionality
• The new functionality does not fit into the memory of the device

To address these two issues, a new custom modification is created, where it defines a new set of features.

tip

• Custom modifications can be public or private (with custom Basename).
• The opening fee for new custom modification is roughly 2h of R&D work.
• New versions are released upon customer requests.
• Application versioning follows the public application versioning.

Custom application

With custom application, there are no limits in the development. The application can be tailored to the customer's needs and can include exclusive custom features, branding, and more.

tip

• Even a custom application can have set of modifications. For example, every vehicle can have its own modification.
• The opening fee for a new custom application is roughly 2 days of R&D work.
• New versions are released upon customer requests.
• Application versioning is independent and exclusive to the customer.
• Customer gets a private documentation for the application under exclusive portal login.

Custom application development

If we receive a request for custom application development, the following steps are taken:

1. Preparation

The customer provides:

• Actual configuration of the siliXcon device (e.g. diagnostic report).
• Actual list of used features.
• Wishlist of features he requests to add.
• Complete electric schematics of the vehicle, incl. pinout of the siliXcon device.
• Communication architecture (e.g. CAN matrix, list of used CAN messages by other devices on the bus, ...).

2. Creation of the custom application

siliXcon will make a fork (tepmplate) from the public application where unused features are removed. The customer then tests the template application, without new features, for initial verification that the functionality did not change.

This step usually takes 2-4MD.

3. Adding new features

siliXcon will start adding new features from the wishlist and gather more information from the customre, if necessary.

4. Testing (and deploying a stable release)

During the development, the new features are continously added to the nightly branch for immediate testing. Once all features are implemented, the testing branch is created for test commitment and verification. At this point, a changelog is introduced and a new version is released.

After the tests, once the customer commits that testing firmware state can be promoted as stable, the stable branch is created.