Navigating the Road to Success in IoT with Comtech

Beth Rominick: Hello, and welcome to today’s web seminar, navigating the road to success in the internet of things, sponsored by Apexon and featuring speakers Sanil Pillai, director of Apexon labs and Brian Salisbury, vice president of product management at Comtech Telecommunications. I’m your host and moderator Beth Rominick. Thanks for joining us today. Before I hand it off to the speakers, I’ll explain the controls on this console. The three panels on your screen can be moved around and resized.

At the bottom of your console you’ll also see a widget toolbar through the additional resources widget on the right; you can download a pdf of today’s slide. If you experience any technical issues, please send us a note through the question field beneath the panel and we’ll be on hand to help. Our responses can be read in the Q & A panel to the left. This is also how you submit questions.

There will be a Q & A session at the end, so feel free to ask questions throughout the presentation. And finally, to optimize your bandwidth for the best viewing especially, please close any unnecessary applications. This even it being recorded and will be made available to watch on demand. Once the recording is ready, you’ll get an email with instructions about how to access the presentation. With that, I’d now like to hand it over to Josh Galde, director of marketing at Apexon for a brief introduction.

Josh Galde: Great, thanks Beth. And welcome everyone. Let me first by introducing Sanil and Brian, your two presenters today. Sanil is director of Apexon labs as Beth mentioned. He is an experienced engineering leader for mobile and enterprise applications. He has built and managed offshore and on site engineering teams, managed mobile projects for fortune 500 clients, and has deep technical and functional expertise in mobile and enterprise applications.

Brian is the vice president of product management for Comtech, as Beth mentioned, which is a leading provider of mission critical wireless communication solutions. He is responsible for a range of location-based service applications and the associate technology platform, which is used by mobile network operators, handset manufacturers, and auto companies. He has more than 30 years of experience in the wireless industry with emphasis on mobile data and location-based services.

He has worked in many parts of the ecosystem, from semiconductor and device manufacturers to software solutions and mobile network operators. Having lived and worked in Silicon Valley since 1993, Brian has been actively involved in the evolution of connected solutions leading up to the present internet of things. He holds a bachelor’s of applied science degree in electrical engineering from the University of Waterloo in Ontario, Canada. I now would like to toss it over to Sanil, who will take it from here.

Sanil Pillai: Thank you, Josh. Good morning or afternoon everybody, depending on where you are dialing in from today. IOT is a term that is used almost every day in some context and hence there is a lot of interest, but also a lot of confusion around it. So today what we want to do was throw some light on some of the nuances of the ecosystem, and what does testing and development for IOT really entail. We’ll cover some of these fundamental concepts, and we’ll deep dive into some of the development and testing challenges for IOT and how to work on those.

And we’ll also cover a very important use-case for IOT which is around connected cars. Before we begin, let’s look at – as I mentioned because IOT has a lot of intrigue, what we are curious to know is the level of adoption of our participants for an IOT initiative they have already embarked on. So are they at the beginning of the initiative or are they much ahead of the game. So if you could please put in your responses, and I think the results should come up in a few seconds here.

Alright, I think it looks like – alright that’s very interesting and I think that this webinar would be perfectly addressing the needs. So there are at least more than half are either exploring use-cases or they have just started an ongoing development around IOT. And the group with not IOT initiative, I’m pretty sure that this webinar will cover some of the important aspects, which will help you kind of take some decisions around IOT going forward. So let’s get started with some of the initial fundamentals of IOT. IOT landscape in general, and a quick primer around that.

If you look at where we are and where we are going to be in a few years from now, today IOT landscape is going through a very interesting inflection point essentially. There are needs for enterprises to increase efficiency and build interconnected systems, but at the same time, the skills for it are in shortage. Because we have new paradigms and new technologies to kind of build upon and they’re a little different from traditional software. Enterprises as you see on the left-hand side, are sitting on a lot of data, that it is getting from the existing systems and existing sensors which might be out there, but really there is not clear standard to leverage the data in a meaningful and uniform way.

There are a lot of products out there which are used for analytics, but each of them has its own idiosyncrasies, which enterprises upload and then kind of adopt to. And we have a lot of IOT platforms in the market. If you look at the cost of sensors, they’ve fallen dramatically. So all the statistics of the cost of a sensor in 2004, was about $1.35, today it is about $0.65, and in 2020 it’s going to be about $0.38. These lowering cost of sensors definitely has led to higher options, but the landscape to manage all of that is still complex.

So let’s fast forward a few years from now to 2020. IOT systems and ecosystems are going to allow enterprises to really leverage the data for real-time decisions and also optimizations in a meaningful manner. Digital business transformation efforts, which exist today, today a lot of them are driven by – earlier they were driven from the movement to web and then they were driven by the movement to the mobile first strategy, and going forward you’ll see IOT as one of the main drivers of these additional transformation efforts.

There’s going to be tens of billions of devices in use, and that’s a billion with a B. So what that means is that you not only have a lot of data coming in, but you’re also talking about extreme connectedness between all these devices. And hence the expectation around contextual relevant data are going to be much higher than they are today. So what that implies going forward is that the business processes that are critical for enterprises and also the features that are prioritized by vendors for IOT products, they definitely have IOT inherently baked in as a core philosophy of how these services or these products should really behave.

And this will have a far reaching implication. If you look at the next slide, this kind of shows you what the untapped potential is. So in IOT we have a lot of things today which are just waiting to come online and be part of the ecosystem. There are some numbers, 300 million utility meters today, and they’re not yet connected. So once they come online and are connected to the larger ecosystem, just imagine the kind of data and the kind of interaction that they would expect and they would contribute to the entire IOT ecosystem. We talk about IOT and agriculture and there’s a lot of progress on that front, but there probably – that’s just one aspect, there’s probably 1 millions vineyard acres which are still waiting to be connected to the entire ecosystem.

We have connected cars and we have autonomous cars, which are slowly getting mainstream traction, but we have 150 million unconnected cars which are still waiting to come online. So when they do come online, what are all the implications of this? When they do come online, we will need to make sure that they can really coexist with other things in the system, and more importantly, really leverage the benefits of technology like location et cetera, which Brian will talk about in a few slides later. Because they need the right context to really be in the right ecosystem in the right manner.

Some of these basic technologies that are building blocks, like location, are going to be really crucial for a very good strong functioning IOT system. In the IOT landscape, it really is all about connectivity. Obviously the key differentiation from today is all about connectivity. When we add context to it like location, it becomes really powerful and really meaningful and that is when the real power of an IOT system can really be leveraged. In the next couple of slides, let’s look at what does that look like. What does the IoT landscape look like in terms of connectivity and then what are the nuances around it?

If you look at the slide you get a sense that it’s not just connectivity, it’s extreme connectivity. You have different protocols and we have two different sections shown here. There is one which is the consumer side of IoT and the other one, which is the enterprise side of IoT, which is more IIOT. So you can see that there are broadcast connections, there are point to point connections. MQTT and COAP are still the most widely used protocols for communication. Great network connectivity to power an ecosystem, you need to have great, resilient network connectivity.

Because a lot of the interactions that happen in IoT really are transferring data and then making sense of it. You need cloud analytics in a big way. Because what you do with these data is not as important in terms of providing the right analytics but also in terms of device proscriptives, recommendations around it so that you can actually fix and self-heal systems which are in place. So cloud analytics is really a big component of IoT itself. And last but not the least, really, if you look at it these systems really are not monolithic. They are really a composition of a lot of different micro-services which kind of come together, each providing its own niche as part of the system.

And that also means that there is lots of integration with other players and other partners in the system. So this is really one aspect of what an IoT landscape looks like. And given that kind of a background, I think it’s important to talk about what are the nuances and complexities of IoT testing. I think this shows the most important aspects of any testing that is done for an IoT product or a service. Of all of the important things that you would see, right in the middle is the idea of hardware and software convergence. So in IoT, a lot of the interactions that happen are at the confluence of hardware and software.

That data can get put in a certain context and then gets processed. So what that means is that in of any kind of IoT testing that we do, the interaction between these two layers, with firmware and with hardware, needs to be tested at a point where any data that gets thrown out is validated for the right context and also the right value. There’s a huge volume of data. IoT data usually are short payloads, but they are huge bursts of data. And the testing for volumes of data which are intermittent, which may not really be uniform in nature.

How you test for those scenarios is very important, and that is different than how do you test typically and e-commerce system, which typically is either a lead-heavy or it’s a right-heavy kind of test. They are very distributed in nature. IoT by definition really means interconnectedness between many devices that actually come together, so the testing strategies for defining and helping with IoT really need to have the support for testing multiple systems which are moving in tandem and addressing the dynamic nature of the entire ecosystem. The devices themselves have very low footprints, they are very low capacity.

So what that means is that any agents that you would typically install on a mobile application, for example to actually test mobile applications, as a strategy may not always work with IoT because the amount of memory footprint you actually have to consume is pretty limited. And so you have your device strategies to circumvent that. Then of course the automation challenges around it. So typical automation strategies which allow you to work with an endpoint and drive it all the way through now have to be scaled out so that you can really have automation across multiple endpoints, which are moving in synchrony and that you need to get data points from all of them to really decide what the automation results look like.

So what kind of testing really helps with IoT challenges? Really here, you have four different kinds. You can use component validation; we can have functional validation, performance or security validation. So in component, really it’s around hardware. It’s around sensor validation, embedded software. And you talk about functional validation, it is really around device interaction, it could be around handling. You really need to make sure you’re doing valid calculations, looking at your even registers and making sure they are recorded properly.

And performance, because the volume of data performance is so key, so synchronization for example, interrupt testing. How do you handle multiple requests? And what is the consistency of data that really moves back and forth. These have to be tested within performance. Last but not least again is security and data. So with IoT and with the whole distributed system, security becomes of paramount importance. So how do you make sure that security is baked in, not only from an access perspective, but also from the integrity of data that moves between different pieces of an IoT system.

What are the encryption strategies? How do you test around it? What are the user roles and permissions? These are the different nuances of testing that exist for supporting an IoT landscape. So if you look at the landscape and the kind of testing you would need, I think they question is really where do the bugs exist, and what kind of testing strategy really helps with different kinds of bugs. If you look at IoT as a landscape in terms of layers, if you move from left to right you’re really moving from the device and to the right you’re really moving all the way to the variant, which is on the cloud or the mobile application.

Starting with the device really starts with sensors. The sensor could be anything, a pressure sensor, light sensors, et cetera. And the bugs could be around accuracy, sensitivity, resolution, so it’s important to make sure that we are looking and detecting those kind of data points when you’re testing at the sensor side of it. Around sensors, power consumption is very important, because these are very small devices with low power capacity. If they work, great, but if they’re consuming a lot of power they’re not going to work for too long. So you have to test for those aspects.

It’s very specific to sensors; this may not apply to other applications. As you move to the right, then you get into the controlling layers. Control layers are mostly the SOCs and you have onboard mechanics and onboard electronics which need to be tested, because your sensor could be working great, but when you put it on a board you may realize that there are data integrity issues which are introduced which may not really be a sensor issue but may actually could be a simple thing like a voltage which is not the right value for a controlling layer. How do you test around these aspects? These are the kinds of bugs that are part of the controlling layer.

Then comes a very important layer which is the communication layer. As I showed you in one of the previous slides, IoT is all about extreme connectedness. So any testing strategy which does not cover communication is not going to be comprehensive enough to really test the entire IoT strategy. So we need to make sure that we are testing not only at the hardware interface side, but you’re also testing more on the communication side, on the software side too. And when we talk about IoT communication, really there are two key things among other things that really have to be taken care of, bandwidth and latency.

So it is important to add up the range. It is important to make sure that we are looking for bugs, which are related to bandwidth, latency, and range. Because these are the different aspects in the communication layer which can really render your IoT ecosystem not functioning to its optimum – in a very quick manner. It is at this layer that the issues around security also get introduced in a very meaningful way. So security testing really needs to happen very strongly at the communication layer. As you move further right, then you get into the session layer. So session layer really is where a lot of these messaging protocols come into play. You could have MQTT; you could have CoAP, et cetera.

Now the bugs that get introduced here are going to be around protocol mismatch for example. You have signature issues, you have backwards compatibility issues. Then of course you have sync issues. So the kinds of bugs that you have here are more the system seems to be working fine, but then you really see that over time your system deteriorates in performance and those are the kind of bugs you would typically find in the session layer. An interoperative is very important, because it at this layer also that you’re really integrating with different partners and different systems.

So the kind of data you can consume, as a consumer and the kind of data you can provide as a provider have to be in sync with what you expected or what is expected from the system. And finally, we have the solution layer, which is really the cloud. You have analytics here and a lot of the big data inside that come into play here. So we have to basically – bugs are mostly around have you designed for streaming data or have you designed for more offline processing? Are there bugs around storage? You have a huge volume of data coming in. Does your system really perform to its optimum?

How real-time can your analytics really be, or is it mostly – are they really push forward related bugs here? And finally when you talk about mobile apps, the mobile apps in the case of an IoT not only have the typical issues of bugs related to a mobile app in any scenario, but there are also specific issues around what kind of an offline strategy does it have? When it comes into an IoT ecosystem and when it goes out, is it able to elegantly come on to the system and bow out of the system? Does it have the right communication protocols built in for communication et cetera?

So these are typically the kind of bugs you would find in an IoT system. The kind of testing that you would really need to do for supporting that would be you would either need some kind of test vet so that you really set up test hardnesses, which really test out a particular area of the IoT system. For example, you could have beacons built in so you really need a test hardness for testing beacons specifically, so you address the real issues around that particular communication. You may also have the need of a test lab. A test lab essentially is where you have an entire set of hardnesses, so a lot of this is built in.

Not only are your actual core testing being done, but also the right methodologies of testing are being followed, so that you have the different layers covered in device form and in device priority. You may need certification programs to be built in so that not only is your system functioning and you have no major bugs in the system, but also they are certified to optimally perform to the existing industry standards. So these are the different testing that should be kept in mind when we actually get into testing for these scenarios. So having that kind of a groundwork for IoT and the nuances for testing and what kind of bugs could be found, at this point I would like to hand it over to Brian, who’s going to talk about a very important use-case for IoT and which is around connected cars.

Brian Salisbury: Thank you, Sanil. We at Comtech definitely see the connected car as a part of this bigger ecosystem that people refer to as the internet of things. I think everybody you talk to has a different perspective on what the internet of things really is, and it’s probably going to continue to evolve over time. We think of the connected car as sort of being one of the bigger types of things that are in the IoT space.

There are many use cases and scenarios that may be pretty much just contained just to the automotive segment, but there are also a lot of very interesting use cases emerging where the car is needing to communicate with other types of things that are part of the IoT to enable various things to happen, whether it be to improve the safety or the comfort of the driving experience, or if it is focused more on the operation and reliability of the vehicle, or if it is perhaps tied into capturing information that is used to help improve the ongoing planning and maintenance of a road networks et cetera.

This slide here, the overview of connected cars, gives a high-level summary of how diverse the elements that go into the connected cars can be. As I said, sometimes things are more focused on the people in the vehicle, and that’s really where the infotainment and content aspects come. Historically, people had an AM/FM radio, and that evolved over the years with 8-track players and cassettes and now today people’s expectation is that when they get into their car, they should be able to access the same type of information and entertainment content that they can get when they’re at home or from their mobile device.

So this has definitely increased the importance of the car itself being connected to the internet, and it also brings with it a need to manage and present that information in a way in the vehicle that is safe. So the type of interaction for the driver needs to be more controlled and constrained so they can continue to focus on driving the vehicle, whereas for the passengers in the car, they should have more freedom to give more of their attention to the content and the entertainment and not have to worry about driving the vehicle.

The telematics area has been in place for quite some time, but it has been fairly limited in terms of capabilities because the connection to the vehicle in the past has been a fairly narrow bandwidth and it limited in the capabilities of the kind of information that it can provide. But now that many new vehicles are starting to ship with a 4G wireless connection that’s actually built into the car, and as well a range of companies that are providing OBD2 dongles that you can purchase and plug into the car.

This is enabling the vehicle to have a much broader bandwidth and a very high quality connection to the internet, and that can be used to help improve the navigation experience by providing real-time traffic and weather and other types of content into the navigation system. It could be used to actually monitor the way in which the vehicle is being operated, and if you’re a good driver and utilize that type of capability to help lower your insurance premiums because the insurance company has proof that you adhere to the speed limit and you do come to a full stop at the intersections, et cetera.

In the emergency services area, we are seeing a lot of interest in using, for example, the fact that an airbag has deployed and that the vehicle is going to need emergency services. In the past a separate call would need to be made by the driver or by another passenger in the vehicle in order to get the emergency services people to arrive. Now vehicles can detect if the airbag is deployed and the car itself can contact emergency services. And then there’s a range of diagnostic capabilities as well. In terms of the overall operation of the vehicle the fact that it’s connected is adding a lot of capabilities.

Then we have the future, near-term future I would say is that the vehicles are going to be able to communicate with and among themselves to be able to share information. So that a vehicle that is encountering a section of road that is perhaps congested or the surface is slick and the traction is poor, that can be detected by sensors on the vehicle and shared with other vehicles that are following so that you have an anticipation that there’s a condition ahead of you and that can allow you to adjust the way that you’re driving the vehicle.

As well there can be parts of the road infrastructure, whether it be toll gates or other access mechanisms that your vehicle can communicate with on its own, and that can help to ease the traffic and improve the quality of flow of vehicles through that area. And then a lot of attention these days has been placed on the autonomous operation of vehicles. Some of that attention is good. Some of that attention has been not so good, but there’s clearly an evolution that’s going on in the industry to enable self-driving vehicles to become a reality a little further down the road.

It’s good that it’s happening in phases, because what can be done with the technology today is to assist the driver, and have a more enhanced cruise control type of operation where the vehicle can drive itself under limited control, but it’s still really the driver’s responsibility primarily to be driving the vehicle. The connections can provide the additional data that can help the vehicle operation be guided but not completely controlled by the system in the car. Also to help detect that vehicles have stopped ahead of you, where the driver may be temporarily distracted, the vehicle can actually take over the braking or provide an alert to the driver to jolt them back to paying attention.

And then the longer term view of course, the vehicles will be angled to drive themselves, but there’s a lot of work that has to be done in the industry before that becomes a commonplace occurrence. So for us, we are creating solutions that we can interact with the car manufacturers to incorporate some of our technologies into their vehicle. They’re realizing that historically their business has been around motor and engine technology, designing comfortable interiors, building a lot of hardware, and that they may not necessarily have all the skill sets to create a connected car on their own.

So it’s very much a strategic alliance type of approach that the car makers are taking and looking for partners that can bring the technology to them and help them to accelerate the way in which they evolve the design of their vehicles. Again, this is largely driven by the customer’s expectations of what you can do today on your cell phone; you should be able to do that in your car. That creates a whole different approach to the design and testing that the car manufacturers have to do. Mobile operators are also very interested in the vehicle because vehicles represent a large audience or a large customer base for them to have subscriptions to the carrier’s services.

So that has really started with providing the basic connectivity, but of course mobile operators don’t want to just be a dumb pipe. They want to be able to add value, so you see a lot of initiatives happening in that space. For example, you see Verizon acquiring companies like Hughes, Telematic, to business bring the knowledge and the skill set of the Telematic space and the connected vehicle space, to bring that knowledge into the operator, so that they can design services that are more complete and deliver those to the automotive companies.

And then also the dashboard is starting to open up a little bit, and some of the auto manufacturers are enabling an application development environment to exist so that third parties can take their applications and adapt them for use in the vehicle. Again, this has to be done in such a way that it isn’t a distraction to the driver, but at the same time provides a rich enough experience that it meets the expectations of the consumer. I think music applications like Pandora as an example, are becoming very commonplace now in vehicles, and that’s going to continue as we move forward.

This is some research that has been done just to gauge what is the level of interest and where are the opportunities here in the US market for people that do own or lease a vehicle. You can see that the interest level is actually pretty high but it’s not extremely high. There’s very good opportunity and it’s something that we’re investing in quite heavily and a lot of companies are investing in this space.

I think that as more people start to have the enhanced experience that comes from being in a connected vehicle, if this type of survey were done in another year or so, you would expect that the interest levels would be even high than the percentages that are shown here. Many times people just don’t understand how some of these things could work until they have the opportunity to experience them firsthand. So I think Josh was going to ask a question at this point in the process. I’ll just pass back to Josh momentarily before I go on with my next slide.

Josh Glade:Thanks Brian for doing that. Please go ahead and fill in your answer. The question is: what is the outsourcing model of your IoT testing practice? Obviously a connected car is one, but this also applies to other industries. Would it be a no team is in place, or maybe you have your in house team. Is it partially outsourced, or maybe all of it is outsourced? Please go ahead and answer that question, and it looks like we have our results. It looks like currently no team is in place, and that’s very interesting with most of the audience responding. So, various things that tell the story around IoT testing and your practice. I’ll go ahead and go to the next slide and toss it back to Brian.

Brian Salisbury:Thank you, Josh. At this point what we’d like to do is talk about a specific project that we’ve undertaken with Apexon. It was actually built with Apexon’s support utilizing a platform that Comtech developed and has been evolving over the past several years. We call it Location Studio. People that are interested can actually go to www.location.studio website and see more detailed information. Essentially it’s a platform offering software as a service and it has three primary areas of functionality. The one that we call GeoSuite is really around enabling the display of maps, the calculation of routes, the delivery of turn by turn directions and guidance, and the incorporation of a lot of real-time content like traffic information, movies and events, gas prices, et cetera.

All of that type of content plays nicely into the connected car to enhance the experience of driving the vehicle and riding in the vehicle. Then we have a Positioning Suite, which is used to actually determine the position of things. In the case of a vehicle, you generally think of vehicles as being outdoors when you need to locate them, so naturally things like GPS have been used for that purpose for a long time. Of course, vehicles do spend time moving indoors as well as in areas where the GPS signals are blocked or interfered with, so there are some other ways of combining signals from sensors in the vehicle to help make up for the temporary loss of GPS and feed that information into the applications that are running inside the car.

That’s another area of functionality that location studios support. Then the other element is messaging because generally with mobile devices that are mobbing between locations, you may want to send an alert when a vehicle arrives at a certain place or when it departs a certain place, or when it is a certain distance or time away from a destination. So our platform provides a very broad range of messaging capabilities. These three areas of functionality within the location studio platform can then be utilized in developing and actual application. So what we’re trying to do with our platform is work with key partners, such as Apexon, to create essentially a reference design for an application in a particular market.

For the connected car area, we’ve worked with them to enable our platform to be incorporated into a solution that has a pretty good range of functionality, but is ready to essentially be customized by an auto manufacturer or another partner to adapt to their specific requirements without having to redesign from the ground up. And it is built on components that have been thoroughly tested and inter-operate together very well. I think at this point what would be good is I’ll pass things back over to Sanil and he can talk about the way that Apexon actually worked with our platform to create this connected car reference solution.

Sanil Pillai:Thank you, Brian. So as Brian mentioned, Comtech has an excellent quite of services which provide different aspects of location and adding enhancements to an entire IoT use case. What Apexon has done was basically integrate those into an application and try to bring the three pieces together as an application that can really show a connected car use case. So we built the integration points and the mobile app into these components of our integration. The important part, the very crucial part was to make sure that this particular application could really be branded.

So there were some architectural decisions made and designs done so that you could actually have a generic template that can really be co-branded, depending on where this is app is installed. Putting that together was a very important aspect of working very closely with the Comtech team to make sure the back end can support some of the required elements, as far as integration went. And one of the important aspects also was to make sure that we were working with them while the back end service is also optimized.

These are various services with lots of capabilities, and we had to have the strategy in place so that we could not only leverage the latest capabilities that we added to these services as we were undergoing with the development but also at the same time we could continue on our own stream without having dependency issues. Lastly, the need was to have a quick reference solution. So time was of essence, and Apexon worked very closely with Comtech to make sure that the reference solutions were brought out really quick and could be put up really fast.

A great example and a showcase of development and working with different constituents geographically distributed and also providing different aspects to the old solution. Some other important pieces of the solution essentially were to kind of make sure that the joint solution can be put together. It was important to provide a very sleek and modern interface as a solution, so that the different ways to navigate components would be really expressed in a very intuitive fashion for the user to use. So Apexon really handled all the UI design, the application design, all the way up to integration and testing.

Talking about testing, some of the challenges of testing such a solution obviously is to make sure that we can get location which really represents the location of a moving car. There were a couple of things we worked with Comtech on to make sure that we had reference solutions and reference data from the back end which would mimic different kinds of movement and trying to work with these kinds of test data. We also built mock services and mock applications on our side to replicate this data. So data replication is an important aspect of these kinds of testing and it really surfaced very well when we actually built an application with Comtech.

Because you have to simulate different locations scenarios, whether it’s in a garage or you’re out in the open. Each have their own nuances as far as testing attributes really go. So the goal for us was basically to build a solution and kind of open up new opportunities for Comtech, yet allowing them the flexibility to modify it as need for other solutions. Going forward, Apexon is working to develop new services, which will link connected cars with connected families for tracking and safety.

In addition, Apexon is posting the contact solution onto different platforms, which could be used by other automotive manufacturers so as to expand the base that the Comtech services can deliver. The key outcome of this development and testing solution essentially was to make sure that the new integrated application really gave Comtech a better way to promote their connected cars. That was the goal right from the beginning and also the UI really stands out from the competition. It is a configurable UI which can be co-branded, so that really gives a lot of advantage of how it can be in terms of scaling the application to multiple OEMs.

Also the whole process of getting the quick prototype up and running in just a matter of hours and not weeks helps to quickly test out the solution on a new OEM really quickly, and in a very creative fashion. So the development cycle that it takes to really take it from the identification of an OEM to actually having it tested is really short, and the reason being the right elements are part of the development process and the architecture to support this kind of a need in the future.

That sums up the key outcomes of this engagement with Comtech. At this point, I would like to throw out a poll again to the audience. The poll is about having heard about IoT nuances and heard about connected cars, having heard about the testing challenges and how to overcome it, I think the question is: are you interested in talking to experts from Apexon about IoT testing, and of course we will get the results quickly. Thank you. And I think with this Josh, I would like to hand to it over to you.

Josh Glade:Thanks, Sanil. And thank you everyone for joining us today. You will receive an email in the next 24 hours with this slide presentation, and a link to the webcast replay. We also have a great promotion right now to take advantage of our free, no obligation assessment that Sanil might have mentioned around our IoT testing and with one of our IoT testing experts. If you have questions, please contact us at info@apexon.com to talk to a representative. I’ll now pass it back to Beth to close out. Thank you.

Beth Rominick:Alright, thanks very much Josh. The speakers will now be taking your questions from the audience. We already have some here but feel free to continue asking questions by typing them in the text box beneath the panels on your screen and clicking submit. Alright the first one I have here, this person wants to know: Why should an enterprise work with a third party for IoT testing?

Sanil Pillai:I’ll take that. I think IoT testing, if you look at the breadth and the depth of the testing that is needed, and important component of IoT testing is having the right infrastructure in place. Also building out the right hardnesses to actually optimize your testing. That, essentially, takes time and effort and also it needs a lot of the right integrations in place. It eventually ends up being a build versus buy situation and because the complexities involved, it is often better to work with a third party, who has these hardnesses in place already so you don’t have to go through that ramp up before you start your IoT test.

Beth Rominick:Okay thanks very much for that answer Sanil. Next question: What are the key elements of an IoT testing practice?

Sanil Pillai:For an IoT testing especially, I think one of the important aspects is going to be to make sure that there is coverage across the entire breadth. Because IoT cannot only be testing around sensors, or not only testing around cloud. You need to have enough testing across the breadth, because all the systems really interact in a very dynamic fashion to build out a final solution, so that is going to be one key element. To have the breadth of testing. The other aspect of an IoT testing practice is that it needs to be modular in nature so that there are certain aspects of the IoT testing, or certain layers of testing which could be done independently also.

Because you could have everything else in place and everything is working fine, but you just need a really in depth testing in a certain area. So although you have a breadth of testing, the testings have to be modular enough that they can be run independently if required. Of course, the third part is having the right infrastructure in place, interconnected infrastructure which can be scaled very easily. I would say these three are the main tenants of an IoT testing practice.

Beth Rominick:Okay, those are all some great points, thank you. How important is automation in IoT testing?

Sanil Pillai:Automation is very key. As you saw in the earlier slides, the complexities of IoT testing are numerous and there are a lot of different moving parts. So in order to have repeatability, in order to have scaling involved, any kind of testing in IoT needs to be automated because you need the ability to not only be able to programmatically tweak parameters in your testing, but also to have the right frameworks in place so that you can really get real-time data in a meaningful way. It is especially because of the dynamic nature of IoT that automation is very paramount. I think you can do a bit of manual testing in IoT, but that is just at the initial level. You really need to have deep automation testing to really make it successful.

Beth Rominick:Okay, thank you. I’m going to ask that anybody interested, take down Apexon’s email address or phone number right now, so that you can take advantage of the free, no obligation assessment to talk to one of their IoT experts. And with that I will say that’s about all the time that we have, so that will be the conclusion of this web seminar today. I’d like to thank our speakers, Sanil and Brian, for their time and Apexon for sponsoring this web seminar. And also a special thank you goes out to all of you out in the audience of course for spending this hour with us. So have a great day and we hope to see all of you at a future event.

Sanil Pillai:Thank you, Beth.

[End of Audio]

Duration: 48 minutes