OpenPV^® 3.x introduced many new architectural changes which are designed to position the platform to be used in a much wider number of targets. New features have been added as well as improvements in extensions such as CAN services which now allow greater flexibility dynamically changing message ID's at run time.

• • • • • Overview
        • BSP Changes
        • SDK & API Changes
        • Minor Changes
        • Migrating to Extension Based Architecture

OVERVIEW

New Extension Architecture –

Much of the functionality previously included in the “Core” is now moved to a new extension system.   With extensions, the Ahsoka.Core library and features have been dramatically reduced in size and complexity.  This decreased size helps us to focus on stable long-term interfaces, higher code coverage of unit tests and decreased coupling between core features and optional features.     As part of this, some of the workflows you are familiar with may have changed specifically around setup of services in the developer toolkit as well as the enabling / selection of which extensions are needed by your application.    The following services are no longer part of the core and are instead enabled with extensions.    

• Storyboard API’s and Code Generators
• CAN Services and Code Generators
• Bluetooth LE Services
• Data / Caching Services

Functionality and APIs for these services have remained largely unchanged so with a small amount of reconfiguration in the Developer Toolkit and very minor code changes, your application should run as it did in 2.0.    The following sections will cover how to upgrade and what changes have occurred in these new Extensions.

Target Support Re-Packaging –

As we move to supporting more diverse hardware, we have restructured the Target Support packages to include most of the artifacts needed for developing on or targeting a platform.    Components such as Hardware Definitions, BSPs, BSP Upgraders and Platform Specific Binaries are now all carried in the Target Support Package eliminating the need to carry them in the core or provide separate downloads.  In addition, “Generic” Hardware Definitions are now provided to allow running OpenPV^® on Non-Supported Platforms such as “ARM32 or ARM64” based systems such as Raspberry Pi, Beagle and Ubuntu based Linux systems. 

Security Features –

3.0 now supports several new security principles and features that can be enabled by application developers.    Customers can now replace the use of general Enovation Controls RSA Keys with their own keys stored in the Customers Project Artifacts.      Keys can be managed for device connections, package encryption (.opv) as well as service authorization.    See the document “OpenPV^® Security” for details on how to use the OpenPV^® Security Features.

Custom Installs and BSP Upgrades –

3.0 now supports the ability to create “Custom” OPV Packages.   These packages can optionally any combination of Application, InstallerUI, Firmware Upgrader and Boot Logo.    

 

Optimized Service Manager –

A new Optimized Service Manager option has been added.  This option creates an optimized service application which includes all extensions.  This enables improved boot times (especially in QT / CPP applications) by pre-compiling the service executable for the target platform as part of the "Generation" process.  Note that this requires the DotNetSDK be installed from the Plugins Tool.

Diagnostic Event Manager Service Extension-

This new service allows any services or customer applications to collect system events in a central location and assign rules around when these events turn into errors in a system.  This service supports AUTOSAR style debounce rules to filter notifications when these system errors occur.   Events can be enabled / disabled in the Extension Configuration Screen. Note that not many of the services currently produce events however over time, we will be adding system events for common failures and errors in the system where you application may need to respond such as temperature and voltage changes etc.

Browser / HTML 5 UI’s –

Customers can now build Browser based applications which are hosted by our native Web Browser.   Based on webkit this browser can host 2D and 3D Web Applications running locally or remotely.    A demo application is included showing how to build a website which interacts with the local hardware to show various system information.  Note that this feature requires the latest 3.0 BSP for OpenView Select Series displays.

Remote Desktop Support –

Customers can now use Remote Desktop to connect to displays to gather screen shots and interact with applications remotely.   New tools are provided on the Target window to enable / disable and start sessions. Note that this feature requires the latest 3.0 BSP for OpenView Select Series displays.

Debug / Symbol Support –

For customers developing applications in C#, we now publish source and symbols via SourceLink allowing customers to step into our OpenPV.Core code directly.

BSP UPDATES

Starting in OpenPV^® 3.0, customers can now field upgrade the BSP to add support for new capabilities.  This is accomplished by using the Custom Install tools to add the “Firmware Update” component to the OPV File.  You can also deploy the BSP upgrade as a separate .OPV file by creating a custom install with only the firmware upgrader. This upgrade will not impact the existing customer application so is useful when a BSP upgrade or fix is needed.

In addition, the 3.0 Select Series BSP has several new capabilities available.

• Support for Ethernet Dongles (uses DHCP by default) for internet / network access.  This feature is automatically active when the USB Port is role swapped to “Host”
• Support for ECDSA and ED25519 Security for Enhanced SSH Security.
• Support for exFAT USB Thumb Drives for wider compatibility with widely used formats on large drives.
• Support for Remote Desktop Access.    When enabled (Enable RDP button) via the OpenPV^® Toolkit, customers can start a Remote Desktop session (Start Session) on the display to capture screen shots or remotely interact with the screen.  Note that this feature should be enabled / disabled for use as it has a large CPU impact on the running application

SDK & API CHANGES

• Storyboard Service and CAN View Models now require passing in the Metadata Factory in their constructors.  These new objects are generated by the respective code generators so should require only a small change to your startup or view models in these systems.
• New VSCode / CPP Demo and Tooling to allow C++ Development (Without QT) for those customers that prefer to work directly with the SDK.
• CAN Applications can interact with the full J1939 Address / Header structure using the model without having to use Promiscuous Modes.
• We have removed the need for an AhsokaRuntime in most scenarios.    Starting Services now involves simply uses the .Start() or .Stop() functions on your Service Clients.   Many of the functions for AhsokaRuntime are still in place in 3.0 however they are marked Obsolete (Depreciated) and will be removed in 4.0. Also, if AutoStartService is enabled for the service (on the Services Tab), services will start automatically on first access eliminating the need to issue the .Start() directly.

MINOR CHANGES

• Toolbar Changes - Generate and Load are now available on the Main Toolbar when a package info file is open, so you no longer must return to the Packaging tab to execute these operations.

• Packaging Tab - The packaging tab now has options for selecting the Signing Key (for encryption when using custom package certificates.   Also, developers can now launch their Project (C#) or Container (CPP/QT) using the Launch Project button.

• Options Tab – OpenPV^® 3.0 introduces a new “Options” tab which allows configuration
  • of any package properties that are specific to the type of device being used.    For example, for devices with a display, the Logo and Orientation has moved to this location.
  • In addition, this tab houses the new “Custom Install Package” tools.  This tool allows the user to create a Custom .OPV File which contains only the components needed.   This is useful when doing partial updates such as upgrading the Distribution Firmware (BSP) or Splash logo without removing the customer application.  Any or all the components can be included in this custom .OPV File including…

• • Update Application – This is the software you have written for the target.  Unchecking this will leave the current application in place and only update the other components
  • Update Installer UI – This will update the Installer UI which you see when loading new applications.    This is useful to get the latest installer with features such as license retrieval from Spark, Notification Support etc.
  • Update Firmware – Checking this option will add a package to your opv file which will execute a delta upgrade to the display’s BSP.   This package will work for any Distribution after “2023-06-09T124926.kirkstone.d9ece39” (the earliest production BSP) and will upgrade a Select Display to the latest 3.x BS.
  • Update Boot Logo – This will add the Boot Logo to your update package.  This is useful when you want to upgrade ONLY the boot logo and leave other components in place.

  • Note that the default “Generate” button always includes the Customer Application and Splash Logo so Custom Packages are only needed when you want to deviate from the standard package.

• Development Tab – This Development Tab no longer includes UI Settings specific to the User Interface architecture as these are now moved to the “Extension” if used.   Also, developers can now launch their Project (C#) or Container (CPP/QT) using the Launch Project button.

• Extensions Tab – This new tab is used for managing extensions used in the project (See extensions section above).

• CAN Tab – The CAN Configuration has moved to the CAN Extension (if enabled) with the same functionality that was available in 2.x

• Behavior Changes – A few places have changed behaviors in the developer toolkit.    The major difference is the work that occurs when adding the SDK to your application source code.    
  • Code Generators now run when adding SDK’s rather than running as part of msbuild or cmake builds.  This does mean you must click the add SDK any time a change occurs to a module (SB or CAN).
  • Client Code is generated for CPP when adding SDK’s instead of being included as part of the precompiled binaries.

Hardware Support – New Hardware Support Added

• Hardware Support is now available for Generic ARM32 Targets (experimental) as part of the OpenView Target Support Package

MIGRATING TO EXTENSION BASED ARCHITECTURE

Starting in OpenPV^® 3.0, many of the services have moved to an external module called an “Extension”.  This change was intended to reduce coupling with the core functionality and enable both internal and external implementation of extended / value added functionality to the OpenPV^® Platform.   To migrate from a core module in 2.0 to an extension in 3.0 is relatively straight forward.  For the most part, the system will attempt to upgrade your package when opened but there are a few manual steps you should complete.

1. Download the Extension Packages (OpenPV^® Extensions).   This package(s) is in the Plugin Window and included by the various Workflows so for most users, you will have the extensions already.  Note that while this is a single download currently, extensions will be separated out into separate downloads in later releases (likely before the Public Release of 3.0.
2. Enable the Extension – To enable the extensions select the “Extensions” tab of the open package.   Here you will see any extensions that are included in the current downloads folders.     Any configuration for the extension will show in the “Configure Extension” button on the right of this window.   Important Note for CAN Users – The CAN Configuration is no located here. 
   

 
 

Once you have enabled the extension, the extension is now able to provide the following to the system.

 

• Code Generators – Extensions can provide code generators that are run at “Generate” or at “Add SDK”.  Depending on the type of code being generated, the code will now be generated in one of those two scenarios.   For example, the CAN Code Generator now runs each time you run the Add SDK or Generate buttons to create models for your application.    Note that while code generators can still be run as part of your native compile workflow (msbuild / cmake) it is no longer necessary.   Most demos have removed this tooling and now rely on the Developer Toolkit to run the generators as needed.  In addition, most demos now include pre-generated code as part of the package.
• Command Line Extensions – Extensions include their own “Commands” to the Ahsoka.Commandline interface.      Once added, these extensions will be in the “Extension” folder under the command line when it’s deployed to your project or to the target.     Extensions have several uses including running code generators as well as executing extension specific commands for use runtime or development time.   For example, the CAN Commands for “—GenerateCalibrationFromDBC” and “--GenerateCANClasses” are both now Extension Commands.
• Editors and Configuration Files – Extensions can each provide its own configuration files.    This allows extensions to provide configuration data structures and file types independent of the core system.     These configuration files are optionally managed by the extension by using commands such as code generators or by providing a user experience to allow the user to configure the module via an Editor (UI) that is provided to the Developer Toolkit.  This allows the editors to be created / owned by the extension owner but to provide a native user experience directly in the Toolkit.   For example, the CAN Configuration and CAN Database Editor are both implemented as Extensions in OpenPV^® 3.0.
• Services / SDKs – Extensions can each provide “Services” and APIs to OpenPV^® Developers.   These services and any other APIs are delivered as part of the extension package and are added to the developers target development environment depending on the selected Development Language. 
  
  • Dotnet / C# Applications still use the native “nuget” packaging system.   To add an extension to your development system, you should add the equivalent nuget package to your project.    Ahsoka.Core.CAN for example.   Each of the extensions are now available in nuget.org for inclusion in your application.   For most C# users, they will simply add the various extensions to their project and compile as usual.    APIs should remain largely the same with some minor changes unrelated to extensions.
  • C++ Applications receive their extension support when clicking the “Add SDK” button on the Development Tab.   As before, the SDK is added to your project, however you will now find a few more items have been generated.  For any service you have added as an extension, the client code is generated for your project to match the currently installed extension.  In addition, extensions can provide language specific SDK code in the form of .h and .cpp files that are also added to your build environment.  For example, CAN based view models are now injected into the customer application instead of being compiled into the core “.so” for the platform