Percepio has launched a browser-based sandbox for developers to test out technology for monitoring remote nodes and sensor across the Internet of Things (IoT).
The DevAlert cloud-connected tool uses an agent in an IoT node to monitor activity and alert developers if there is a problem, ideally before this becomes apparent to any users. This provides a diagnostic feedback loop from remote devices to developer and support teams, with visual trace diagnostics that can reduce debugging time by 80% or more.
The package runs an open source emulation of an ARM Cortex M4 microcontroller in the cloud, running a sample application of an elevator controller with lots of bugs to show how the alerts work.
“Setting up device feedback loop can be complex as it may involve a mix of embedded software, cloud and desktop software and you need all parts in place to evaluate the solution,” Johan Kraft, founder and CEO of Percepio in Sweden tells eeNews Europe. “We wanted to reduce that and make it a smooth ride so you can try it out quickly. You don’t need any cloud skills to set up DevAlert Sandbox, so embedded engineers can get started in a few minutes.”
“We did a lot of customer meetings last year and realized we needed a more realistic demo application, that is really easy to get started with and also allows for experimenting with the code,” he said.
“Everything is integrated as a ready to run package,” said Kraft. “This is an interesting way to use a virtual platform. I’ve seen a lot of activity in virtual platforms for embedded development, so it fits in with the trend.”
Percepio chose the open source xPack QEMU package rather than ARM’s virtual models, and it can be run locally as well as in the cloud.
“We wanted something that we could control ourselves without dependencies on ARM, so we found this open source tool, but it’s the same concept,” said Kraft. “The xPack QEMU simulator runs on the same machine as the graphical interface and the Eclipse IDE, and we provide a virtual desktop in the browser.”
“Another way to use it is to download a virtual machine image and run it locally. This way you can set up multiple instances of the demo application, all reporting to the same DevAlert account. We recommend using the downloadable version in case you want to experiment with the code. The web version has streaming graphics so it’s not as responsive as a local virtual machine.”
“We needed a buggy application for the demonstration as a way to show off the monitoring feature, so we developed this application using Tracealyzer continuously for debugging and noticed some issues so we left them in, so they are organic bugs rather than synthetic examples.”
The application allows the user to change scenarios and parameters in the code and recompile and run remotely.
“A drawback with using virtual machines is it’s not as fast as native and the software performance will depend on the underlying host computer. This makes it harder to demonstrate elusive timing-dependent software issues. But in the cloud version we have a very consistent performance which means we can reliably demonstrate even elusive timing bugs,” he said.
The sandbox uses a shortcut to make it easier to get started. “There are no TCP/IP or TLS stacks in the example application but data is uploaded via semihosting and background tools. DevAlert is normally used with TLS and certificates, but can be used with any communication protocol. All that is needed is a way to upload a block of data. How this is implemented is outside the scope of DevAlert Sandbox and we wanted to avoid additional complexity from certificates and provisioning of the virtual device.”
“DevAlert is designed to leverage the existing connection of the device to an IoT gateway, such as an AWS IoT Core or Microsoft Azure IoT Hub. The devices would normally not connect directly to DevAlert, but the integration happens in the cloud. With the sandbox we avoid the need to setup such a cloud integration and the upload is instead made directly to the DevAlert API,” he said.
After the 15 day evaluation period there are two paths to take, he says. “You can integrate DevAlert on your hardware and upload to the DevAlert API via a small tool that reads from the debug interface, or you could go all in and set up a DevAlert connection in the cloud backend of the device. This way, the DevAlert data is uploaded just like regular application data.”
“We separate the data handling so most of the data stays on the OEM side, in particular the traces that are recorded. This means only metadata needs to be uploaded to DevAlert for indexing and classification. The benefit of having this in two steps is that we can provide a fully managed service but the initial upload and data stays on the customer side,” he said.
The graphical interface is hard coded so it’s not a general purpose simulator, but it allows Percepio to develop other demos using the same concept, he says.
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.