Remote Process Control Using a Reliable Communication Protocol
•Descargar como PPTX, PDF•
1 recomendación•395 vistas
Remote Process Control Using a Reliable Communications Protocol - US Ignite Application Summit 2013
Recomendados
Más contenido relacionado
Similar a Remote Process Control Using a Reliable Communication Protocol
Similar a Remote Process Control Using a Reliable Communication Protocol (20)
Más de US-Ignite
Más de US-Ignite (20)
Último
Último (20)
Remote Process Control Using a Reliable Communication Protocol
- 1. Remote Process Control using a Reliable Communication Protocol George Adams1, Doug Comer1, Rajas Karandikar1, Bhaskar Sarma1, John Geske2, Alison Chan2, Judi Clark3, Pat Kennedy3, Jim Morrison3, Tracy McSheery4, Greg D’Andrea4, Dmitry Derevyanko4, Ernest Howland5, and Ralf Muehlen6 1 Purdue University 2 Kettering University 3 Lit San Leandro 4 PhaseSpace, Inc. 5 OmNom Project 6 Internet Archive
- 2. We want to rely on great Apps that rely on great Internet communication
- 8. Internet communication Reliable Assured Real-time
- 10. Delay search 500 ms = Revenue/user down 1.2%
- 11. Delay search 400 ms = Searching down 0.74%
- 12. What to do? • – Gigabit broadband – Software defined networking • Create and manage multiple paths
- 13. Internet with multiple paths RC End System RC End System
- 14. Internet with multiple paths RC App RC App
- 15. Internet with multiple paths RC App RC App
- 16. Internet with multiple paths RC App RC App
- 17. RCs learn in real-time RC App RC App
- 18. Build replacement path with SDN RC End System RC End System
- 19. Multiple paths in the lab
- 20. Multiple paths across the country
- 21. 3D Printing in San Leandro, CA
- 22. Gigabit Video Monitoring • Monitor the 3D printing process • Super HD camera • 100 frames per second • Gigabit video
- 23. Process control in San Leandro
- 24. Team
- 25. Support
- 26. Reliable, assured, real-time Internet communication • Send multiple copies • Over different paths • Learn which paths to use • Built new paths as needed A fundamentally new Internet service
Notas del editor
- Hello, my name is George Adams and I lead the Mozilla Ignite team developing the Reliable Communication Protocol for Remote Process Control for applications in Advanced Manufacturing and many other areas.
- We want to rely on great Apps that RELY on great Internet communication.
- We want our voice and video calls to be high-fidelity, high definition, highly available, and to work flawlessly until WE are done.
- We want to reach out from wherever WE are to manufacture advanced parts anytime and anywhere.
- We want to control shared,advanced means of production without having to travel.We want to connect manufacturers so they can more easily form innovative supply chains.
- We want Apps that communicate life-critical information – vital signs and vital treatment directives -- while we are on the way to the hospital.
- And when we arrive, we can have remote expert consultation and mentoring available to the local doctor and, if needed, tele-robotic surgery performed by a highly experience practitioner. Bringing health care expertise to the front line.
- To achieve this we need Internet communication that is reliable, assured, and real-time.But is it these three things?We all know that the the answer is no, no, no !
- The Internet behaves this way because it is a one lane highway.Each packet follows a single path from sender to receiver.If any link along that path is congested or has failed, delivery of that packet is affected. The receiving App suffers and the sending App is unaware for a long time.Apps that depend critically on receiving all packets in a timely manner will not work or will be too risky.This situation is not only a problem for Apps of the Future.
- We have stormy weather today.A study for Bing showed that a mere 500 ms delay in returning search results decreased revenue per user by 1.2%.
- A Google study published in 2009 showed that Inserting just 400 milliseconds of delay into Google search led after 4-6 weeks to users performing 0.74% fewer searches.And after that delay was removed, searching did not return to pre-study levels, even after another 4-6 weeks.Not so lucky.
- The answer is US Ignite, which is about gigabit broadband and also about software defined networking.
- We begin with two End Systems connected to the Internet represented as a collection of networks (yellow clouds) themselves connected to form the Internet and then with software defined networking we have Redundancy Controllers labeled RC connecting each End System to the Internet.
- Create and manage redundant paths with SDNRedundancy Controller (RC) sends 2 copies of each packetThe sending Redundancy Controller will send two copies of each packet of information.We now see an End System ready to send a packet, that is replicated, sent over the two paths, and merged at the receiving Redundancy Controller, which delivers the information to the receiving End System.
- Create and manage redundant paths with SDNRedundancy Controller (RC) sends 2 copies of each packetRemote RC monitors paths and delivers packetsBecause the receiving Redundancy Controller receives both copies of the packets under normal conditions, it can monitor the condition of each path.
- A network problem, shown by the red link, is detectable by delayed or failed arrival of packets on one path.
- Remote RC detects network problem (red link) because redundant packet is delayedRelays problem information to sending RC and SDN builds new pathThe Redundancy Controller can use this information to trigger construction of a new path, shown here in purple, restoring redundant paths, and maintaining reliable delivery of packets.FIT IN REDUCED LATENCY GRAPH AROUND HERE??????Transition: Now this is where it gets exciting.
- * What was an exciting moment in the development or end-user testing of the application? There were many moments of excitement. Our work started in the lab, and we were very pleased the first time we saw packets traveling along multiple paths. Then we used the National Science Foundation GENI platform for network experimentation to create multiple paths spanning the US. It was satisfying to see communication continue when one of the paths through the Internet became congested. However, the real excitement started when we could disable one of the paths and see our software select an alternative and when we controlled a 3D printer remotely and monitored the correctness of its behavior in detail with HD video.
- Multiple paths with SDN using National Science FoundationGlobal Environment for Network Innovations (GENI)
- Software-controlled manufacturing.
- This is our team
- The Mozilla Ignite challenge was the catalyst that caused me to act and to form a team, joining universities, a gigabit city, and industrial partners to build construct a practical and effective demonstration that spans the country.
- We can achieve reliable, assured, real-time communication over the Internet if we send multiple copies, over different paths, learn which paths to use, and build new paths as needed.This fundamentally new service will transform what we is possible with the Internet.Thank you.