Embedded Software (ESW) are used in "Mechatronic Products".
ESW is a popular acronym for the electronics that is embedded with the Products we manufacture sell to our customers. Today we assume that such electronics are programmable. A few years ago the intelligence was programmed in EPROMs and was not possible to upgrade or change after the Product had been manufactured and delivered.
The programmability implies that it is possible to upgrade the software after the Product has been delivered to the customer. It is also possible to sell new software with completely new functions during the Product's entire Life Cycle (see Views and Life Cycles).
The ESW in a Product normally consists of several Electronic Control Units (ECU) plus sensors or transmitters of data and cabling between these. The intelligence or Software is programmed and stored in flash memories in the ECUs. The ECUs "are talking" to each other all the time and to the operator's information panel when a warning for some critical condition is necessary or when the operator want some information of some sort.
Each manufactured Product Instance may be programmed individually according to the Customer Order and the pertaining Product Configuration using the Plant Tool. The configuration of each Product Instance is captured and stored in a Product Instance database.
It is possible to diagnose the ESW system at the dealer workshops and in the field to detect possible malfunctions in the Product in via a Service Tool, normally a laptop computer with special applications installed. Comparison with the original or actual configuration of ESW for the Product Instance may be done. The same Service Tool can be used to upgrade the ESW to a later version or to update new functions.
"The ESW Plant"
Software and hardware used in ESW are assigned regular Part Numbers and they are handled very much like any other Part in the Product. These Parts are tagged "ESW Parts". They should never appear in the inventory (except the ECU which again is also a physical Part).
The Software is divided in different classes such as Main Software, Datasets with Parameters and Down Loader used to get the software in place and operable. Parameters, Codes and Signals used internally in the ESW system have to be strictly defined (Sysdata) and have to follow the communication standard chosen for the applied internal networks.
In an Extended Enterprise with several PDM applications it should be wise to extract the ESW appurtenant information and capture and store this in a separate database tied to the ESW applications. At each Plant manufacturing the Products belonging to the Enterprise, there will be a Client/Server installation to take care of the Programs Packages received per Product and configured to fit each Product Instance to be manufactured.
The common ESW applications may be regarded as an "ESW Manufacturing Plant" to be used by all Plants building Products with ESW. That is, "one ESW Plant for the whole Enterprise".
This will also ensure that
- ESW will be handled regarding validity and effectivity in the same way across the Enterprise.
- ESW will be downloaded into the Products in the same way using the same Manufacturing Tool.
- The Configuration of the Product together with the ESW configuration is recorded in one Product Instance Database for all built Products in order to allow one single Service Tool with one single type of access to this information.
- Tool upgrades follow Product Enhancements in an orderly manner in order to safeguard serviceability.
This has been done recently at Volvo and at Volvo Construction Equipment with great success.
With ESW it is essential that the Service Tool is ready to provide service the very moment when the Product hits the market. It is necessary to have a coordinated introduction of Engineering Changes to the Packaging Tool, the Manufacturing Tool and the After Market Tool. This is done through a Cross Functional ESW Council which coordinates the Effectivity of Engineering Changes depending at which Earliest Date these Tools can be upgraded.
The graph is showing how such Tool upgrade runs are handled in a sub-system of the ESW Application. Data and Functional consistency is checked and accepted upgrades are reflected in the PDM/ESW db with tags for ECNs and ESW Parts upgraded in the Tools.
Input for each run is controlled and scheduled by the ESW Council for all Products, Product Companies and Plants within the Extended Enterprise.
The Packaging Tool may be a mainframe application while the Plant Tool is a client/server application at the Plant and the Service Tools are laptops served from an After Market server.
The Electronics as such are always based on standards. SAE standards are commonly used within the automotive world. Such standards define Hardware and Software Interfaces between the ESW in the Product and the Manufacturing Tool and the Service Tool. They also define how data/signals are being communicated through the internal communication network between the different ECUs and the sensors/transmitters used to induce signals (temperature, pressure, RPM, torque etc.). The software parts and data are strictly defined and described in the Sysdata. The Sysdata is attributed with Captions in several languages in order to let the Service Tool interact with people at all important markets around the world where the Products are being sold and serviced. New ESW functions introduced by Engineering Changes will normally require new Sysdata and Captions.
Plant Tools and Service Tools will have to be ready to manufacture and service the Products simultaneously with the Packaging Tool.
The After Market Tool should be ready to service the Products the moment the first Product with the new ESW function starts down the line! This calls for some cross functional coordination throughout the company. Hence, the Software Council.
The ESW Process
The ESW Process covers nearly all the Major Processes in the Enterprise – creation of the Customer Order may be outside the ESW Process.
It starts with Product Development where the ESW Engineering develops the Software and the Hardware to be used in the Product Instances. All possible Options will have to be foreseen. The ESW Engineering also updates all Sysdata needed in the ESW Tools and by the Driver etc. Most of the Options are handled by Parameters and Parameter Values. The basic Software normally handles all predefined Options.
The Hardware as well as Software, Parameters and Description Files will be assigned Part Numbers. However, these Part Numbers will have special Part Type related to what types of Parts they are.
At Volvo they divide the Software found in the ECU in different portions :
- Down loader
- Main Software
- Dataset 1
- Dataset 2
- and possibly sub-datasets.
The Datasets normally contain the Parameters and Parameter Values.
When all this is defined and ESW Engineering has released this on an ERN/ECN, the information is available for the rest of the Company.
From the ESW Councils, people involved will have learnt what will come and when it will come. They have had time to prepare.
The Effectivity of ERN/ECN will have to be decided in an ESW Council where all concerned parties are present.
Very often it is not just a change in the software. There are other changes to the Product Structure that has to be synchronized. This is handled by the ESW Council where people from Manufacturing were consulted long before the ERN/ECN was released.
Each ERN/ECN has to be implemented in the three tools:
- The Packaging Tool
- The Manufacturing Tool
- The After Market Tool
All the tools will have to be in tune to make it work.
Finally when all this is ready it is time to make the Engineering Change effective: Effectivity Date is reached.
Manufacturing can now start to process Customer Orders that may include the new functions and finally start assembling the first Product Instance with the new functions.
The After Market Tool is ready to
- service the Product Instances built with the new functions and
- to sell the new function to owners of older Products and
- to invoice the customers for the costs
The After Market Tool is using the Product Instance Database to verify that the Software that is present in a Product Instance being served is the correct Software and that it is the latest available etc. The Product Instance Database is updated when the Software Package for a certain Product Instance is being processed. What goes into the Product Instance Database will always relate to what Software is being loaded into the Product Instance being built at the Plant.