The requirements for discrete manufacturing companies are changing due to various factors. More and more the software of the product and the related features decide if a product acts as key player in the market or not. Nowadays engineering companies which dealt the last centuries more with mechanical and electrical parts are facing the challenge to adapt and integrate software into their product development and product lifecycle processes.
This article gives a short overview how software can be managed and integrated into SAP, enabling the business to deal with software in R&D and subsequent logistic processes like production and service.
The enterprise should be able to answer questions like:
- Which software version is compatible with module X?
- Which version is available and should get flashed to the product on the shop floor?
- Will the software of single components work together on the hardware as designed?
To solve these questions the business has to manage the software in the ERP to get a harmonized view on all components of the product, regardless if it is a mechanical, electronic or software part. There the paradigm should be: Handle software as a part! Now the question arises how can enterprises achieve that? In the following article I will try to answer that question and give some advice how a basic workflow could look like.
In order to make it more feasible, just take a car as an example. A car consists out of several subsystems, so called ECUs (Electronic Control Unit). Each ECU is designed for a dedicated functionality: e.g. Airbag-ECU, ABS-ECU, ESP-ECU, etc. Every ECU contains software to control the different subsystems. The management of the different versions and releases is a complex and error prone process. However, there is still one layer of complexity to add: Integration. Integration is the major factor and decides whether the product will work properly or not. All subsystems have to work together properly to ensure for example the safety of a car. That means: Is the ESP working together with the ABS? Or before the final system test: will both systems compile together and still perform as designed? This is especially a challenge if the modules get developed by different teams or get delivered by different suppliers.
These questions are quite new for DI companies but not for a pure software vendor. The answer for that challenge is Continuous Integration (CI).
I will now give a short overview how the software delivery landscape should look like. Within this article I will not go into detail how to setup a multi stage project or which CI build configurations should get configured. This includes also the question where you should run automated tests on real hardware in case of embedded software development. For sure the answer is quite simple – as early as possible, but just imagine that a mid-range car costs ~35.000€ and you cannot give every developer or every team a dedicated car for testing.
Let’s get started with the landscape:
1. Use a Source Code Management (SCM) System – Code Repository
Every software component has to have a dedicated source code repository to manage different versions, branches and keep the history of the commits. There are a lot of solutions out there to use. Based on the team size, commercial aspects and
the desired architecture (distributed or central) you can choose between GIT, SVN, Perforce, ….
2. Use a Continuous Integration platform
A CI platform takes care of the integration and build activities of a software component. This includes not only basic compiling and linking steps, but also testing and publishing activities. A CI build can get triggered by a new commit or in a multi stage environment by a successful CI Build of a dependent software component in order to ensure that the new version of software component A integrates with the latest version of software component B.
All these activities and related tests (either on real hardware or a virtualization environment) can get automated. This reduces the chance of a manual error and speeds up the delivery process. Basically the aim is to ensure the quality, consistency and reliability of the software and reduce the time to delivery of a new software version. Also here a large variety of CI platforms is available. A few examples for a CI solution are: Jenkins, TeamCity, Travis, …
3. Use a Binary Repository
If a software component version passes the production gate the CI platform will generate the final tested, released and signed binaries, which can get flashed on the final product.
The binaries and the related documentation have to be saved to make them accessible for production and service organization. This could be a CVS system or a dedicated tool like artifactory or SAP DMS.
4. Integrate software as a part in your PDM/ERP system
In order to track the compatibility and usage of the software, basically to see it together with the mechanical and electronic parts, you should transfer the software versions to your ERP/PDM system. That does not mean that you have to move the binaries to SAP, but at least the software components and the information about the available versions should get maintained there to make them available to the business.
The product development would then be able to design the specific software components to the different BOMs and keep track of the usage of a specific software version throughout the whole Supply Chain and BOM Lifecycle (as-designed, as-planned, as-built, as-installed). In addition you can build up a compatibility matrix between your mechanical, electronic and software parts as you have all information in one unique system, avoiding the design of incompatible components or enabling your service engineers in the field to flash the proper software version on for example a filling machine on customer site, which at the end will save a lot of time and money.
The manual creation of the master data is not manageable, especially in the area of software development where you could face multiple commits every day. SAP provides a solution to overcome this issue of integrating your software development process with the consulting solution Software Control Center (SCC)
SAP Software Control Center
The SAP Software Control Center deals with the challenge of integrating new software versions into your SAP ERP/PLM system by creating master data based on CI builds and the provided metadata. Keeping track of the origin of the software version via the provided metadata of the connected CI platform is a key factor to be able to manage the whole software lifecycle.
Functions:
- Integration of open source CI platform:
How can we take advantage of the existing software development standards?
The solution integrates the de-facto standard Continuous Integration platform Jenkins. Through this integration SAP can connect to all common Source Code Management systems like Git, Subversion and Perforce. Additional CI platform integrations could be added in the future.
- Management of Software within SAP:
How can we monitor our software within one central system?
The solution allows to create a representation of each system within the software development landscape. All components can be monitored from SAP PLM and can provide a quick access to the native system itself.
- Bug tracking:
How can we trace the health of a software project?
The solution can be integrated with the most commonly used bug tracking systems like Bugzilla and Mantis. Based on this integration the release readiness of a software version can be determined.
- Reuse of SAP standard master data:
Can we use the objects of the Software integration in SAP ERP processes?
The solution introduces only one new object: The software component. This object can be linked to a SAP material master. All other objects get represented by an ordinary SAP ERP object like DIRs and classification. So there is no restriction to use the integrated data in subsequent logistic processes.
Slide Deck - Software Control Center
Webinar (german)
If you are interested getting you software landscape connected to SAP, do not hesitate to reach out to me and we will get in contact.
PLMServices@sap.com
Pascal Kugler
Business Process Consultant PLM
SAP Consulting
- SAP Managed Tags:
1 Comment
