Cloud computing and software-as-a-service (SaaS) usually mean that end-users do not purchase software products or conventional licences; nor do they run the software on their own hardware.
Instead, they dispatch their tasks via some form of “light” front-end (a browser, for example) to run to completion elsewhere, whereupon the result is returned to them. To execute the tasks, server instances are drawn from “the cloud”.
Do such models have anything to offer embedded product development? After all, software tools represent a large budget for any complex project. Most or all of that cost is upfront, and tools need frequent updates.
Users often over-provision to ensure the availability of licences at key project stages, adding further cost. The cost and complexity are particularly challenging for small and medium-size enterprises (SMEs).
Using SaaS avoids large upfront costs. Users pay only for the compute resource that a task demands and for only the time it’s needed; they also devolve tool version control to the software vendor.
SaaS providers can create pricing models that provide attractive alternatives to upfront capital costs. So why is it not already more common?
SaaS in electronic engineering
There are precedents for SaaS in electronic design. Hardware emulation is one example. Hardware emulators represent an extreme in terms of cost and usage; they are expensive and tend to be used intensively but episodically in the life of a project. This has led to business models in which their builders retain ownership of the hardware and either lease them or “sell cycles” of its capacity. However, such arrangements have been the exception rather than the rule.
Engineering users inevitably have concerns about their unique intellectual property (IP) being exposed when it is in the hands of a SaaS
In practice, this will be a matter for binding legal agreements between service providers and customers that stipulate that the tools will respect IP confidentiality. Physical and procedural safeguards to protect against wayward activity must support these agreements.
Bandwidth requirements will vary depending on whether the user chooses to store the project data in the cloud or locally. The storage decision will affect the amount of data that has to be transferred into and out of the service-software environment.
Some technical computing tasks will be interactive; others will be more batch in nature, requiring bandwidth only at the beginning and end of a design stage.
It’s only a matter of time before a complete embedded tool chain will be found in the cloud, but the environment for an embedded SaaS offering will look somewhat different from that of a commercial offering.
It will be feasible, for example, for the provider to host multiple versions of tool software and to give the user some control over which version is to be used. Then the chosen version of the tool set becomes one of the attributes of the project until deliberately updated, and version conflicts are avoided.
The way in which SaaS is charged will give providers opportunities for differentiation and customers will be able to choose the charging model most appropriate for their business. Pricing models might be by activity, by design stages completed, with or without a subscription element, and so on.
Freed of the upfront licence fee model, software tool vendors will be able to charge for their services on a basis that links their offering more closely to their customers’ activity level and their success, which will be of particular interest to SMEs.
SaaS is a natural derivative of cloud computing and, assuming the perceived risks are properly addressed, will soon provide a commercially and technically compelling alternative to conventional software for embedded system development.
Author is Mike Beunder, CEO of Vector Fabrics, a software tools firms based in Eindhoven.