To the Cloud and Back Again – Different Simulation Environments for Different Users
By Graham Morphew
I’m not a very mechanically inclined person, even in the abstract. In fact, in university, the grade that I received for my 2nd year mechanics course was a visible blemish on an otherwise, pretty darn good academic record. Take my car for instance; I can do a few basic things to maintain it. I can replenish fluids, replace wiper blades and change tires but I really don’t enjoy doing any of that much. I bought my car to drive it, not fix and tinker with it. I don’t have any need for a lot of expensive automotive tools or time to spend underneath it. And while my car is not perfect, I would never attempt to build one for myself to perfectly fit my needs. I marvel at people that buy old cars and restore them to the former beauty. But for me that is not how I would ever want to spend my “free” time. I’m not a “power-user” in the automation market. Like the majority of people that own cars, I prefer a much simpler interface with my vehicle.
I’ve been working with two products over the last few years than make me think about this relationship of the so-called “power-user” and masses of regular users. A few years ago, I joined the product management team for the Wind River Simics product line. This is a simulation product that can do some amazing things. You can create models of hardware boards and large scale systems. You can save the state of a simulation and restore it later at that exact point in the execution. You can even reverse time (virtual time, anyway) and use the Simics system debugger to step backward in your code. In the hands of the right person, who has a bit of training and some experience, Simics can do amazing things. I have seen examples of this time and time again with Simics customers, and when it is used internally at Wind River.
Now, as a product manager, I live partially in the technical world and partially the business world. At the time when I moved over to the “dark side” (about 15 years ago), from my previous role as a Field Applications Engineer, I thought I had some pretty decent software skills. In that decade and a half since, I have gained a lot of business skills and learned about a lot of new technology, but hands-on coding and software development wasn’t really a big part of my life anymore. So with Simics, I understood what it could do and how it did it but I didn’t have a lot of time for deep-dive technical training and use. So, compared to the “power-users” of Simics that I interacted with, I was only capable of primitive things. I didn’t write models, I didn’t create complex simulations or run new software. I would mostly run the simulations and demos that others built. That’s all I needed to do, and I didn’t do it all that often. I didn’t want to build or fix things. I just wanted to “drive” (to build on the car analogy). I wasn’t completely alone in my experience. We have lots of customers that absolutely love Simics but sometimes our “fans” are small groups of people within very large companies. So when we asked them “If you think Simics is so great, then why isn’t everyone in your company using it?” we would usually be told that it was “too powerful” for regular users like application developers, who just needed to run the simulation and didn’t have time to invest in learning to how use Simics.
More recently, I started working as the product manager for a new product – Wind River Helix Lab Cloud. This product started off as a way to allow people to “just drive” Simics. Lab Cloud allows the “power-users” of Simics to deploy a simulation model and software to run on it in a minute or two, in a Cloud-based web application. For the driver/user there is nothing to install or configure. You can just login, pick out a simulation platform and start it up. This simple interface has allowed me to spend a lot more time with Lab Cloud than I ever did with Simics. The access to different simulation platforms from Intel to ARM and PowerPC is instant and when those platforms are running Linux, I don’t need to configure a complex embedded Linux environment either. If fact, I can even skip right past the Linux boot and get straight to a command prompt. This has helped me beef up on my embedded Linux skills because now I don’t need to get a board or install a Linux distribution. I just start up a simulated platform running Linux and when I need to context switch to something else, I can simply halt the simulation and come back to it later at the exact point I left it.
Behind the scenes there are still Simics engineers that are creating these platforms but now these engineers have a deployment tool, in the form Lab Cloud, to make their hardware/software platform creations available to a much wider audience – an audience that doesn’t need to install Simics to take advantage of Simics simulations. This ability to provide easy access to simulation for non-Simics users was a key initial feature of Lab Cloud and was implemented as the ability to create a Lab Cloud platform from any checkpoint created in Simics. A checkpoint is a saved system state of a simulation and it can be recorded at any point in time of the simulation. This feature, also allows you to create a simulation platform, run it long enough to complete a standard Linux boot sequence (with all those fascinating scrolling text messages) and then save a checkpoint at that point in the simulation, so that you can start from that point later, after the boot has completed. In Lab Cloud, a Simics checkpoint roughly translated into an asset called Lab Session snapshot. With a Lab Session snapshot I can start a simulation, skip the boot sequence and get to a command prompt right away.
Until recently, the flow from Simics to Lab Cloud was one way. For me, it meant I stayed in the realm of Lab Cloud and asked others to build content using Simics. What we found, however, is that occasionally the simple user interface provided by Lab Cloud wasn’t enough to debug a complex software problem. Sometimes, you need to call in the experts. To reference my automotive analogy again – sometimes you need to bring your car into see a mechanic. This made our one-way flow between Simics and Lab Cloud a bit too restrictive, so we implemented a new feature that allows Lab Cloud users to download a Simics checkpoint from an existing Lab Session snapshot and provide that checkpoint to an expert using Simics for further analysis and debugging. What this allows Lab Cloud users to do is transfer a saved state of a simulation from the Cloud to the desktop and hand off this captured state of their simulation in Lab Cloud to an expert user who has the full power of the Simics environment at their disposal. With Simics you can dig deeply into what is happening with the software and the simulation to easily find the root of a problem.
Now Simics simulations can go round trip – in Simics you can create models load software onto them and create a checkpoint as a suitable starting execution point. When you are ready, you can deploy this ready-made simulation to a large set of users using Lab Cloud. If needed, those Lab Cloud users can then bring issues and tough problems back to Simics experts for detailed analysis or inspection.
Full system simulation is a powerful tool for software development. Different users can share simulation assets (platforms, models etc.) using different simulation environments and tools that are specific to their use case and skills. This is a common paradigm with other digital assets like data files, images and executables. As it is with automobiles, there are expert power-users (the mechanically inclined) and large numbers of people that are looking for a simpler form of interaction (those who just want to drive). Having these two “modes of use” for the same asset allows you to get more value out of your simulation assets. Being able to send your simulations to the Cloud and back again let’s more people use them and makes your investment in simulation provide an even greater return. For the non-power users of simulation, like me, Cloud environments provide instant and easy access to simulation making it no longer exclusively a tool of the expert and making it accessible to everyone.