 Hey folks, thank you very much for joining me for this case study of a 2000 in vehicle IoT platform deployment. My name is RJ Mahadev and I'm the global head for remote and mobile assets at Cisco. I hope all of you staying safe and safe wherever you are. And as I walk through this, please feel free to ask me any questions that you have. If you'd like to have a discussion after the session, you can reach out to me over LinkedIn at the address below and I'd love to keep this conversation going. So let's talk about what the customer was looking for when they originally came to us. They had 2000 vehicles with a legacy vehicle logic unit platform on board the vehicle that was sort of the brains of the operation. And it was connected to their RFID systems for passenger counting, their mobile data terminals, all of their video systems, their P systems destination signs, as well as their LMR plan mobile radio. Besides the gateway connecting the VLU, they also had a gateway for their faith payment system. They had another gateway for passenger Wi-Fi and they had a couple gateways for their telematics units on both the vehicle. So as you can imagine, they had a pocket pint of antennas on the roof and a number of implications, right? So one was the cost for installing and maintaining the system. Each of those antennas cost them $1,500 to $2,000 to implement. They needed different cellular and backhaul providers for the different gateways and systems that they had. Operating it was a bit of a nightmare. And there was no security because some of the gateways didn't have encryption. And also, they were stymied in their capability of deploying some of the newer cloud-based applications because of the capabilities of the VLU. They also had scaling challenges. Imagine 2,000 vehicles with disparate systems, different gateways, all of it disjointed, really difficult to monitor and control it. And especially with the desire that their bus staff are able to take care of it without pulling an IT, they had a number of challenges. So their initial requirement coming in was they wanted a system that was simple, secure and scalable. Simple to deploy with zero-touch provisioning that deployed both the gateway and deeply integrated it with their on-board systems. Something that was really secure. So both from the standpoint of providing secure access to their on-board systems by remote maintenance techs, especially at these times of COVID, they needed people to access the vehicle when the vehicle was not at the yard. And also, when the vehicles were out and about, they were constantly under attack, so they needed a really strong cybersecurity protection. And they want to make sure it's scalable. Both they wanted a scalable hardware that was really robust, as well as the ability to support edge compute and a lot of new applications on it. So in order to think about how they could do this, the first thing to think about is the different systems on-board vehicle. So on the right-hand side, you see all of the vehicle operation systems that they had, which was essentially their J1939 and CAN bus for vehicle telemetry. So they could do predictive maintenance on the different vehicle systems as well as get vehicle information like fuel monitoring and breaking information from the vehicle. They had all of the fleet operations that they needed to manage. So this is the CAD-AVL for doing dispatch and vehicle location as well as being able to allow their transit management center to connect to the vehicle. And then they had all of their business operations, so the transit management for customer fare collection, customer Wi-Fi, displace and all of that. So they really needed a system that would support all of these different operations and processes that they had to run on the vehicle. The way we addressed this was we started with something that was really easy to provision. So a process where their network architect was able to develop bespoke configuration for the different vehicle types and was able to set these configurations up in a cloud platform that the bus mechanics could reach. And they could use to deploy the different templates based on the requirements to different vehicles. And one of the innovations that we did was we unified the vehicle gateway ID with the bus ID. So this way they didn't have to remember a gateway MAC address or an IP address. They were able to use the bus ID to inventory and provision the vehicle. The other thing that they wanted to do was a single pane of glass for the SIM management so they could activate, suspend or deactivate the SIM card at the same time that they were managing the gateways. So this way for instance, if the bus was at the yard getting fixed they could suspend the SIM or they could also do real-time rate plan management to where if they were reaching their usage threshold they could on the fly go up to a higher rate and manage overhead charges. So that was sort of the key requirement here was to have a very simple way to provision their buses so the bus could quickly be put into service. The other big requirement they had was for security. Like a number of other transit operators, they had had two operations impacting security incidents in the last three years and they have a huge focus on security. And they wanted a multi-tier security model where they could secure the edge so nobody could get access to their system by hacking into the gateway on the vehicle. So this included having authentication and included having things like accelerometers and GPS asset tracking to see if the vehicle has been moved and having input alarms. They also wanted to make sure that they secured the network communication with things like extending their enterprise security end to end from the vehicle all the way back to their enterprise, having deeper visibility onto the traffic traversing the network having things like hardware-based encryption as well as secure management of all of their hardware and software. And lastly they wanted to secure their applications so they wanted things like audit reports of how applications were being used they wanted to have a hosted application like cycle management and they really wanted to make sure that they didn't have to worry about getting hacked again. So the way we did this was we started with building giving them configurations that provided .1x authentication as well as firewalls in the gateway that was specialized to their requirements. This way anybody getting access to the gateway would not be able to hack into it and get access to the bus systems as well as the rest of the transit systems. The second thing that we did was from the cloud we were able to push out end to end flex VPNs and we're actually able to push out different VPNs so we could provide an additional layer of security for their financial systems so the financial data was kept separated and protected and then we could also ensure sort of higher availability and the confidentiality of the CAD AVL data. The third thing that we did was we integrated with some of their enterprise security with things like umbrella that provided content filtering so this way Wi-Fi users on the bus would not access content that would make other users on the bus uncomfortable. They could do things like identity services management to manage both the devices as well as the identity of the different users that had access to the system and they could do deep packet inspection of the traffic traversing the network using things like self-watch. So all in all this reduced the need for them to go to third party security vendors as well as it improved the protection from evil players and hackers out there. The other thing that the security provided them was an ability to have secure remote access because of this end to end security when they had issues on the vehicle like for instance if their onboard CAD AVL system had an issue at 10pm at night they didn't need to take that vehicle out of service, offload the passengers, send another vehicle out and bring the original vehicle back to the yard. Instead the transit center could contact the bus mechanic and the bus mechanic was able to remotely access the back and the devices onboard the vehicle through the gateway and because there was an end to end flex VPN tunnel this was highly secure. They were able to troubleshoot and do firmware updates to those devices as if the vehicle was back at the yard and this way without taking the vehicle out of service in a matter of minutes they were able to fix the bus and have the system operate smoothly. This secure remote access was a huge boon to the operations and as you can imagine really improved the customer experience as well as their operational processes. The third thing that the customer wanted to do was really ensure that they had a strong edge compute platform and when it came to edge compute they wanted to do a couple different things. They wanted to make sure that they could extract data from southbound systems with pre integrated connectors. So they wanted connectors for J1939 as well as a Modbus and a couple MQTT devices that they had on both the vehicle. They wanted very simple scripts that would let them govern and transform the data. So for instance they could combine data in different ways and they wanted the ability to deliver that data natively to Azure which is where they had a number of the different applications as well as to applications that they had with software AG who was one of their other providers. Besides this requirement for edge intelligence they also wanted to leverage the Cisco IOX platform that gave them a full Linux environment that they could use for deploying microservices. Let me tell you more about how they use this. They were able to develop a full standards based open ecosystem on that vehicle and were able to deeply integrate some of these edge compute microservices with their cloud based applications. And again, this was not a wall garden. This was something where the different partners could develop either virtual machines, VMs or could push Docker based containers onto the gateway because the gateway had processes that were dedicated for the Linux environment. So essentially from the cloud they were able to push these Linux based microservices onto the A29. And they were then able to pull data and push data either to that onboard device or to the transit center or to the public cloud. And there was some very, very interesting applications that they were able to deploy. So for instance, with NetMotion they were able to do better vehicle diagnostics. So they were able to actually map signal strength around the route of the vehicle and figure out when they would use one cellular provider versus the other based on the signal strength that they saw in the route. And they got this information from NetMotion diagnostics. They were able to use swiftly for providing real time route management. So essentially their transit management center had these head ups swiftly displaced that told them where the vehicle was in its route, whether it was running early or late, or if they needed to do something to improve the route so they could really optimize the route. And they were able to use applications from KPIT who built a full TCU stack on the gateway and was able to provide deep onboard diagnostics in a simple heads up display in the cloud. So again, these are just samples of different partner applications they were able to use. In many ways the world was their oyster because they had a standards based system available for developing applications. The TCU stack was especially interesting so drilling into that a little bit more. It was a really low memory footprint and it provided a number of different connectors like J1939, DOI, OBD2 and so it enabled them to use either an Ethernet or a serial based connector to their CAN bus. They could take the data and they had a number of different onboard APIs and a runtime environment that could do both test and diagnostics and they had all of the different diagnostic codes available so they could diagnose information. And they actually had a very rich fog application available that connected back to the cloud so they could seamlessly manage vehicle faults and different vehicle parameters and this was seamlessly managed either on both the device or in the cloud and really gave them a rich set of diagnostic and telemetry capabilities. The other thing that they could do which was really interesting especially because of COVID is by using this microservice they could integrate with their IRIS APC automatic passenger counting devices that were on both the vehicle that had historically been used for providing regulatory information at the end of the day to say how many passengers had been on both the vehicle. They could now access this information in real time and push that to the Swiftly app so this way Swiftly was able to say when the passenger count was reaching the 25% threshold that was required for social distancing on both the vehicle. And so now in real time they could send another vehicle to pick up passengers at the bus stop and they could instruct the vehicle not to stop at stops where passengers did not be to disembark and this way they were increasing the number of passengers onboard the vehicle. The customer found this incredibly useful. The other thing that they were interested in doing in the future was integrating with some of the intersection management applications that the DOT had deployed where for instance pedestrians were detected by the LiDAR system and was sent to the gateway that was at the intersection. And the DOT was able to run some very simple scripts that could send DSRC messages to both the buses as well as to other cars that were on the roads to instruct them that pedestrians had been detected. The DOT could also send a signal to using NTCIP to instruct the vehicles that pedestrians had been detected and they could also warn their DOT traffic management system that there was a potential incident that could happen in vehicles didn't stop. So again a very elegant way to integrate with the intersection something that we've been trying with a few DOT customers in Florida and Las Vegas that they were interested in deploying at their location as well. So again a lot of this was made possible because of the open partner ecosystem. So they had a wide variety of partners that could develop and deploy these applications either their ISVs or they could actually have machines like their sensor or the machines for doing their ramps that were integrated into the vehicle. They could also have their system integrators and their VARs or some of their distributors develop applications or they could even integrate a lot better with some of their service providers or some of their global partners. So really a very elegant edge compute platform that was made available because of having a Linux based development environment available on the vehicle. The other thing that they did was they worked very closely with us to validate and document their end-to-end architecture with a Cisco validated design that provided them documented best practices that they could use for more effective operations and to improve the reliability of the system. And this also provided much better support both from Cisco as well as some of their internal support because they had documented configuration of record that they could use for change management and really drive the simple secure and scalable objectives that they had for the platform. So hopefully all of this gave you an idea of how they were able to combine their provisioning, their security and their edge compute to really have a very effective end-to-end IoT platform. From an IT perspective, this was really the four key components that they integrated, their secure device, the integrated edge compute, centralized gateway management and integrated cellular data management. NetNet, where did this leave them? This left them with a multi-service onboard network that seemed to be connected to a number of different systems that they had at the vehicle. Their payment systems, their signage, their Wi-Fi, their OBD2 and J9339, as well as their VLU and voice. And all of this was done with sort of a two-component solution, their secure gateway with edge compute and a very mechanic-friendly gateway and some management. Addressed a number of the challenges that they had so they could focus on deploying passenger services, it really simplified how they managed the different systems and it was really simple for their gateway mechanics that had previously had a challenge with this. And again, that simple secure and scalable value proposition was very, very useful and interesting to them. The other big benefit that they had was they now had an architecture that some of the other city agencies could also deploy and they had a unified architecture across different agencies. So not only was Mass Transit able to leverage this platform, their first responders and the city fleets and the DOT fleets were also able to use exactly the same platform. So this way they could then leverage their operations across multiple agencies, not only for the vehicle but also for their remote sites like their traffic and roadway sites, some of their pipeline sites, as well as some of the other remote access requirements. So again, as you can imagine, a very simple and elegant platform that they could extend across different spot city requirements. Thank you very much folks for your time. The Q&A is open so do hit me with some questions that you might have. I'd love to have a little bit of an interactive dialogue to make sure this comes alive. So whether you're a transit agency or whether you're a different type of remote or mobile asset user or if you're a vendor, especially if you're a startup. I think this is a very interesting platform where you don't need to worry about the onboard network. You can instead leverage that with cloud based applications and really start selling software as a service in a very effective way to your customers. So do hit me up with questions and if you're not able to have your questions answered during the session, do reach out to me over LinkedIn. I think remote and mobile asset owners are at an inflection point for two reasons. The digitization trends have continued and have actually accelerated with COVID and there's a greater reason for remote management of your mobile assets as well as your remote sites and doing things like predictive maintenance and cloud based applications. And this type of a platform really makes it easy to do that. Take care folks and look forward to interacting with you. Goodbye. So do type them into the chat window and I'd love to interact with you live here. If you can get to your questions here over the chat, you can also reach out to me over LinkedIn and we can have a further discussion. So I'll be around till the bottom of the hour for the next five minutes. While we're waiting, some of you I think might have some questions around more how startups can partner with Cisco to use this platform to drive some of their applications using edge compute. And that's something that we're starting to see a lot of activity with a number of different partners that have cloud based applications that now you can deploy some of those workloads to the edge. And using edge compute you could do a more effective management of IOT data and especially with things like video cameras. You could manage how much of that data gets sent to the cloud and maybe send it when certain events occur as opposed to stream all of that data. So this way you're really sort of managing both your cloud as well as your backhaul costs. And that's actually one of the big benefits we see of IOT is the flexible nature of the platform and the fact that it's sort of a horizontal stack. It allows startups to develop vertical applications that can write this stack and we are very interested in talking to companies that would like to further flesh this out. So that's definitely something of interest if that's the business that you're in.