Massive simulations in the cloud are beginning to replace costly simulation hardware. The automotive industry has discovered the potential of the technology, and they are not alone. Whichever parameters and properties the software needs in order to simulate different environments or sensor and actuator systems can be modelled and run in Docker containers. The great freedom offered by the new technology does, however, pose new questions about the licensing and protection of cluster simulation software.
Regular gamers will fail to see the innovation: For them, simulations in the cloud, openworld games, with thousands or even millions of active systems, sound just like the massive multiplayer online role-playing games or MMORPGs they have been accustomed to since the 1990s. But the key difference lies in the business model: An MMORPG is run in the cloud, and gamers typically pay monthly subscription fees. For licensing purposes, the developer only needs to know that the gamers are who they say they are – the archetypal use case for a USB dongle like the CmStick.
With cluster simulations, as are common in the automotive industry and elsewhere, the business model is quite different. The developer would sell the simulation software to a car maker, who then runs it in their own cloud, e.g. AWS or Microsoft Azure. Now the developer wants to know that the software is not shared, by accident or by ill intent, with others and that the client only uses as many copies of the software as they have paid for.
One condition that often applies is that the cloud software must be identical with the on-premises software. Any compromise on the protections in the cloud would therefore mean weaker protection for the on-premises version, and vice versa. Another crucial condition to consider is that the cloud software would usually be running in numbers that are greater by an order of magnitude compared to the number of on-premises versions active at any given time. It is not unrealistic for the use case to demand 30,000 copies to be up and running within three minutes.
CodeMeter can accommodate all these conditions. The usual best practice would be to maintain a separate Docker container for the CodeMeter License Server, but this becomes unfeasible with the tough performance demands created by massive installations of the scale at stake here. The solution is to place the essential pieces of CodeMeter Runtime in the application’s Docker container and then choose one of two options: For the first option, a CodeMeter Cloud Credential file would be included in each container. The software would then get its license checked by connecting with those credentials to the CodeMeter Cloud Server hosted by Wibu-Systems, which can scale up easily to manage millions of queries in such a scenario.
The alternative would be a custom binding to the environment of the client, e.g. the carmaker: The Wibu-Systems Professional Services team would work with the software developer to produce a special extension for CodeMeter Runtime that binds to a chosen combination of properties of the cloud, such as subscriber or client IDs. Bound to the cloud, the license could only be used in the specific carmaker’s Azure cloud and nowhere else. This option is a perfect fit for enterprise-level contracts that depend on copy protection for the software, but do not need a usage counter.
Whichever option is chosen, the software developer will benefit from the full power of CodeMeter in protecting against piracy and license fraud. The simulation software would be the same, whether it is running as a cloud or an on-premises version, as only the CodeMeter license would need to be customized to the specific use case.