Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ZettaScale - IT Press Tour 52 Dec. 2023 Madrid

ZettaScale - IT Press Tour 52 Dec. 2023 Madrid

The IT Press Tour

December 06, 2023

More Decks by The IT Press Tour

Other Decks in Technology

Transcript

  1. ZettaScale Mission Bring to every connected human and machine the

    unconstrained freedom to communicate, compute and store — anywhere, at any scale, e ff i ciently and securely
  2. Zettlers Values Zettlers are Technology Knights and live embracing the

    Seven Knightly Virtues of Courage, Justice, Mercy, Generosity, Faith, Nobility and Hope.
  3. The Team Management team with 20+ years of experience in

    communication software and related market Strong thought and technological leadership internationally recognised Over 50% of the Engineers hold a PhD
  4. Some of the world most demanding customers and challenging systems

    trust ZettaScale and its Technologies ZettaScale Customers
  5. Locations ZettaScale HQ is in Europe, R&D organised around technology

    centre of excellence in France — (Grand Paris, Plateau de Saclay) — and Netherlands respectively
  6. At the Forefront of Innovation ZettaScale has been identi fi

    ed as one of the 10 startups in vehicle communication to be watched in 2023
  7. Investors ZettaScale is an ADLINK spin-o ff TTTech-Auto has made

    a strategic investment in ZettaScale ZettaScale and TTTech-Auto have partnered to enable fl exible and safe application development for software- de fi ned vehicles
  8. Strategic Industrial Partners Working on the fi rst European implementation

    of a Data Distribution Service (OMG DDS) that ISO-26262 certi fi ed for use in series cars Working on certi fi ed version of Zenoh to support wider range of hardware/networks and early innovators Expanding the capabilities of software- de fi ned vehicles by improving V2X communication and bringing edge computing support through the cutting-edge communication protocol Zenoh
  9. Simplicity does not precede complexity, but follows it — A.

    Perils The Digital Frankenstein Today, building systems that span from the micro-controller to the data-centre feels like assembling a digital Frankenstein Multiple technologies have to be stitched together only to make data fl ow end-to- end Few more have to be packed-up to deal with data storage… Not to talk about computations
  10. One Protocol Can Change Everything What made the ARPANET the

    Internet? The IP Protocol! Before the IP protocol networks were exactly in the same situation we witness today IP became the one protocol to integrate and eventually run everywhere! A Protocol for Packet Network Intercommunication VINTON G. CERF AND ROBERT E. KAHN, MEMBER, IEEE Abstract — A protocol that supports the sharing of resources that exist in different packet switching networks is presented. The protocol provides for variation in individual network packet sizes, transmission failures, sequencing, flow control, end-to-end error checking, and the creation and destruction of logical process-to-process connections. Some implementation issues are considered, and problems such as internetwork routing, accounting, and timeouts are exposed. INTRODUCTION IN THE LAST few years considerable effort has been expended on the design and implementation of packet switching networks [1]-[7],[14],[17]. A prin- ciple reason for developing such networks has been to facilitate the sharing of computer resources. A packet communication network includes a transpor- tation mechanism for delivering data between com- puters or between computers and terminals. To make the data meaningful, computer and terminals share a common protocol (i.e, a set of agreed upon conventions). Several protocols have already been developed for this purpose [8]-[12],[16]. However, these protocols have addressed only the problem of communication on the same network. In this paper we present a protocol design and philosophy that supports the sharing of resources that exist in differ- ent packet switching networks. After a brief introduction to internetwork protocol issues, we describe the function of a GATEWAY as an interface between networks and discuss its role in the protocol. We then consider the various details of the protocol, including addressing, formatting, buffering, sequencing, flow control, error control, and so forth. We close with a description of an interprocess communication mechanism and show how it can be supported by the internetwork protocol. Even though many different and complex problems must be solved in the design of an individual packet switching network, these problems are manifestly compounded when dissimilar networks are interconnected. Issues arise which may have no direct counterpart in an individual network and which strongly influence the way in which internetwork communication can take place. A typical packet switching network is composed of a set of computer resources called HOSTS, a set of one or more packet switches, and a collection of communication media that interconnect the packet switches. Within each HOST, we assume that there exist processes which must communicate with processes in their own or other HOSTS. Any current definition of a process will be adequate for our purposes [13]. These processes are generally the ultimate source and destination of data in the network. Typically, within an individual network, there exists a protocol for communication between any source and destination process. Only the source and destination processes require knowledge of this convention for communication to take place. Processes in two distinct networks would ordinarily use different protocols for this purpose. The ensemble of packet switches and communication media is called the packet switching subnet. Fig. 1 illustrates these ideas. In a typical packet switching subnet, data of a fixed maximum size are accepted from a source HOST, together with a formatted destination address which is used to route the data in a store and forward fashion. The transmit time for this data is usually dependent upon internal network parameters such as communication media data rates, buffering and signalling strategies, routeing, propagation delays, etc. In addition, some mechanism is generally present for error handling and determination of status of the networks components. Individual packet switching networks may differ in their implementations as follows. 1) Each network may have distinct ways of addressing the receiver, thus requiring that a uniform addressing scheme be created which can be understood by each individual network. 2) Each network may accept data of different maximum size, thus requiring networks to deal in units of the smallest maximum size (which may be impractically small) or requiring procedures which allow data crossing a network boundary to be reformatted into smaller pieces. 3) The success or failure of a transmission and its performance in each network is governed by different time delays in accepting, delivering, and transporting the data. This requires careful development of internetwork timing procedures to insure that data can be successfully delivered through the various networks. Paper approved by the Associate Editor for Data Communications of the IEEE Communications Society for publications without oral presentation. Manuscript received November 5, 1973. The research reported in this pa- Fig. 2. Three networks interconnected by two GATEWAYS. larger than this min range growth and communication wou specifying how muc packet size can be, fo 1) If a maximu specified then it bec isolate the internal p network from the int all other networks. 2) It would be
  11. Is IP the Solution? IP is about exchanging packet between

    two machines — It is “Host Centric” The applications are build and use today are data-centric — this mismatch causes a big challenge and an emergence of higher level protocols to deal with it, e.g., MQTT, DDS, etc.
  12. Automotive: The Cost of SOP Delay The cost of delaying

    the Start Of Production (SOP) for an automotive OEM is mostly due to the complexity of SW integration 3.5B€ 6 Month 27M€ 1 Day 1,1M€ 1 Hour
  13. Connectivity & SOP Delays Connectivity today is usually centrally managed

    Connectivity between di ff erent elements of a car is centrally managed It takes several weeks to add a new link
  14. Robotics: Communication Challenge Existing communication protocols pose severe limitations on

    Robot-to-Anything (R2X) communication >20 Years Old Protocols Wireless Highly Problematic Scale Challenges to Scale out and Down
  15. Topology Constrained and Energy Inefficient IoT & Edge: Energy, Scale,

    Topology Increasing challenges faced IoT and Edge applications due to the fact that protocols in use are often 20+ years old and were designed for "another world” Wireless Highly Problematic Scale Challenges to Scale out and Down Energy Incredibly Wasteful
  16. Dragons teach us that if we want to climb high

    we have to do it against the wind. Pub/Sub/Query protocol that Uni fi es data in motion, data at rest and computations from embedded microcontrollers up the data centre Provides location-transparent abstractions for high performance pub/sub and distributed queries across heterogeneous systems ISO-26262 ASIL-D certi fi cation upcoming
  17. Quotes from Zenoh Users "It's very simple to goof around,

    try things etc... It's like a beautiful lake or sea during summer : it calls you.” “Zenoh is literally the answer to all my ROS 2 multi robot system prayers. Thank you for providing a tool that actually works.” “Zenoh is the Kafka of Edge Computing”
  18. In a recent article that evaluates mainstream protocols, including MQTT,

    DDS, AMQP an CoAP Amazon describes Zenoh as: “Perhaps the most viable protocol that will help us mature to this ideal model is Zenoh which is an Eclipse Incubation project” Amazon IoT
  19. Zenoh identi fi ed as the most appropriate protocol for

    V2X applications for autonomous and assisted driving ITU
  20. The Crash Suppose two vehicles crash into each other Wouldn’t

    it be great to be able to retrieve all the data from the digital witnesses? But where is this data? It may only be available on local car or edge infrastructure storage How can we retrieve it?
  21. Zenoh used for V2X communication in the Indy Autonomous Challenge

    This blog describes the the problem it solved!
  22. It's very important to inspire the next generation. Our technologies

    are adopted on high visibility projects in robotics and autonomous vehicles for on device and V2X/R2X Next-Gen Devices built on Zenoh
  23. OpenRobotics carried an independent evaluation on Zenoh and how it

    could improve ROS2 communications — A new hope OpenRobotics in 2022
  24. Zenoh vs DDS Discovery Open Robotics performed a comparative evaluation

    of Zenoh and DDS (full report) The results showed how much more e ff i cient zenoh discovery is compared to DDS 1 8 www.openrobotics.org www.openrobotics.org Some interesting results Discovery traffic versus application traffic Some interesting results Multicast traffic versus unicast and TCP traffic (Multicast is a great way to bring down a poorly-configured network)
  25. 2023-09 ROS 2 RMW alternate Abstract........................................................................................................................................ 1 User Challenges with

    DDS..........................................................................................................2 DDS has a fully-connected graph of participants.....................................................................2 DDS uses UDP multicast for discovery................................................................................... 3 DDS can have difficulty transferring large data....................................................................... 3 DDS can struggle on some WiFi networks.............................................................................. 4 DDS tends to have complex tuning parameters...................................................................... 4 Vendor specific non-standard DDS extensions....................................................................... 4 Next Steps............................................................................................................................... 5 Requirements gathering............................................................................................................. 5 User Survey............................................................................................................................. 5 Demographics..............................................................................................................6 Technical Data............................................................................................................. 6 Alternative middleware options.................................................................................... 8 Requirements.......................................................................................................................... 9 Comparative analysis of currently available middlewares.................................................... 11 Complete list of investigated middlewares.......................................................................11 Performance.................................................................................................................... 13 Middlewares X Requirements................................................................................................13 Conclusion................................................................................................................................. 14 Appendix A.................................................................................................................................15 Abstract The ROS MiddleWare interface (RMW) is an abstraction layer that allows ROS 2 to swap out its underlying communication mechanism (middleware) at both compile time and runtime. All current Tier 1 implementations of RMW are based on DDS. At the time that this solution was chosen, it met many of the initial requirements. Over the last 8 years of use, based on user feedback a number of problems have been identified, including: Intrinsics / Open Robotics in 2023 Zenoh selected as the fi rst non DDS protocol to be natively supported Intrinsic implementing Zenoh RMW as the major contribution for next ROS2 release Very insightful report, worth reading
  26. Dragons teach us that if we want to climb high

    we have to do it against the wind. Pub/Sub/Query protocol that Uni fi es data in motion, data at rest and computations from embedded microcontrollers up the data centre Provides location-transparent abstractions for high performance pub/sub and distributed queries across heterogeneous systems ISO-26262 ASIL-D certi fi cation upcoming
  27. Runs Everywhere Written in Rust for security, safety and performance

    Native libraries and API bindings for many programming languages, e.g., Rust, C/C++, Python, JS, REST, C# and Kotlin Built-in support Shared Memory and Zero Copy Supports network technologies from transport layer down- to the data link. Currently runs on, TCP/IP, UDP/IP, QUIC, Serial, Bluetooth, OpenThreadX, Unix Sockets, Shared Memory Available on embedded and extremely constrained devices and networks — 5 bytes minimal overhead Data Link Network Transport Physical …
  28. Runs Everywhere OS Linux, MacOS, Windows, QNX (alpha) Embedded Targets

    Arduino, ESP32, mbed, Zephyr, and many more Automotive Targets AUTOSAR Classic (microSAR)
  29. Any Topology Peer-to-peer Clique and mesh topologies Client Client Mesh

    Peer Peer Peer Peer Peer Clique Peer Peer Peer Peer Client
  30. Any Topology Peer-to-peer Clique and mesh topologies Brokered Routed Client

    Client Brokered Clients communicate through a router or a peer Mesh Peer Peer Peer Peer Peer Router Client Client Client Client Router Router Client Clique Peer Peer Peer Peer Client
  31. Router Router Any Topology Peer-to-peer Clique and mesh topologies Brokered

    Routed Router Router Router Client Client Routed Routers forward data to and from peers and clients Brokered Clients communicate through a router or a peer Mesh Peer Peer Peer Peer Peer Router Client Client Client Client Router Router Client Clique Peer Peer Peer Peer Client
  32. Storage fleet/1/** Subscriber fleet/*/car/*/position Storage fleet/2/** Publisher fleet/2/car/1/position Publisher fleet/1/car/1/position

    ZZ AWS Azure Private Cloud Edge Server 5G MEC 5G MEC Pull Subscriber fleet/2/car/*/position Storage fleet/1/car/1/** Storage fleet/1/car/2/** Storage fleet/1/car/3/** Subscriber fleet/2/car/*/position Subscriber fleet/2/car/1/position Subscriber fleet/2/car/*/position Pub/Sub Queryable fleet/*/adas/navigation/** Queryable fleet/2/adas/navigation/** Queryable fleet/1/adas/navigation/**
  33. Storage fleet/1/** Subscriber fleet/*/car/*/position Storage fleet/2/** Publisher fleet/2/car/1/position Publisher fleet/1/car/1/position

    ZZ AWS Azure Private Cloud Edge Server 5G MEC 5G MEC Pull Subscriber fleet/2/car/*/position Storage fleet/1/car/1/** Storage fleet/1/car/2/** Storage fleet/1/car/3/** Get fleet/1/car/*/something Distributed Query Queryable fleet/*/adas/navigation/** Queryable fleet/2/adas/navigation/** Queryable fleet/1/adas/navigation/** Subscriber fleet/2/car/*/position Subscriber fleet/2/car/1/position Subscriber fleet/2/car/*/position
  34. Storage fleet/1/** Distributed Query Subscriber fleet/*/car/*/position Storage fleet/2/** Publisher fleet/2/car/1/position

    Publisher fleet/1/car/1/position ZZ AWS Azure Private Cloud Edge Server 5G MEC 5G MEC Pull Subscriber fleet/2/car/*/position Storage fleet/1/car/1/** Storage fleet/1/car/2/** Storage fleet/1/car/3/** Queryable fleet/*/adas/navigation/** Queryable fleet/2/adas/navigation/** Get fleet/car/*/something Queryable fleet/1/adas/navigation/** Subscriber fleet/2/car/*/position Subscriber fleet/2/car/1/position Subscriber fleet/2/car/*/position
  35. Storage fleet/1/** Subscriber fleet/*/car/*/position Storage fleet/2/** Publisher fleet/2/car/1/position Publisher fleet/1/car/1/position

    ZZ AWS Azure Private Cloud Edge Server 5G MEC 5G MEC Pull Subscriber fleet/2/car/*/position Storage fleet/1/car/1/** Storage fleet/1/car/2/** Storage fleet/1/car/3/** Queryable fleet/*/adas/navigation/** Queryable fleet/1/adas/navigation/** Queryable fleet/2/adas/navigation/** Computation get fleet/1/adas/navigation/car/1 Subscriber fleet/2/car/*/position Subscriber fleet/2/car/1/position Subscriber fleet/2/car/*/position
  36. get fleet/1/adas/navigation/car/1 Storage fleet/1/** Subscriber fleet/*/car/*/position Storage fleet/2/** Publisher fleet/2/car/1/position

    Publisher fleet/1/car/1/position ZZ AWS Azure Private Cloud Edge Server 5G MEC 5G MEC Pull Subscriber fleet/2/car/*/position Storage fleet/1/car/1/** Storage fleet/1/car/2/** Storage fleet/1/car/3/** Queryable fleet/*/adas/navigation/** Queryable fleet/1/adas/navigation/** Queryable fleet/2/adas/navigation/** Computation Subscriber fleet/2/car/*/position Subscriber fleet/2/car/1/position Subscriber fleet/2/car/*/position
  37. Zenoh’s Abstractions Universality Zenoh’s abstraction are universal since they allow

    to express the key patterns in distributed computing, namely: Publish/Subscribe. Trivially supported by Zenoh’s Publisher and Subscriber Remote Computation. A Queryable represents a generalised computation, since it can transparently deal with replication and partitioning Storage. Represented by the combination of a Queryable and a Subscriber Additionally all these primitives enjoy location transparency by the virtue of being data-centric.
  38. Zenoh vs DDS, MQTT & Kafka Zenoh can deliver at

    peak performance of ~70Gbps at 8Kb payload: - 3.3x higher than DDS - 23x higher than Kafka - 35x than MQTT (higher for larger payload) Zenoh’s latency 10us (7us for pico) - 25us for MQTT - 75us for Kafka - 8us DDS
  39. 3 Elements of Protocol E ffi ciency Processing E ffi

    ciency. The amount of work necessary to craft a packet when sending user data and symmetrically the amount of work necessary to process a packet when receiving user data. Wire E ff i ciency. The amount of bytes that the protocol adds to user data. Routing E ffi ciency. The distance that the data has to travel in order to get from its source to its destination.
  40. Communication is Expensive The overall e ffi ciency of a

    protocol depends on these three elements each of which has an impact on energy consumption. As a result of the laws of physics, the energy consumption will be dominated by communication. As a consequence, the wire and routing e ffi ciency are the most important from an energy consumption perspective.
  41. Computational E ffi ciency It is very hard to have

    a direct measure of computational e ff i ciency. One way to measure the processing e ffi ciency of a protocol is to look at the throughput. As the throughput measures the number of messages that can be shared between two protocol endpoints per unit of time, it is a very good indicator of processing e ffi ciency.
  42. Zenoh vs DDS, MQTT & Kafka Zenoh can deliver at

    peak performance of ~70Gbps at 8Kb payload: - 3.3x higher than DDS - 23x higher than Kafka - 35x than MQTT (higher for larger payload) Zenoh’s latency 10us (7us for pico) - 25us for MQTT - 75us for Kafka - 8us DDS
  43. Zenoh vs DDS Discovery Open Robotics performed a comparative evaluation

    of Zenoh and DDS (full report) The results showed how much more e ff i cient zenoh discovery is compared to DDS 1 8 www.openrobotics.org www.openrobotics.org Some interesting results Discovery traffic versus application traffic Some interesting results Multicast traffic versus unicast and TCP traffic (Multicast is a great way to bring down a poorly-configured network)
  44. A Question of Balance When designing a protocol there are

    various design parameters to balance Wire overhead is one of these, if constrained environments are relevant Historically, wire-e ff i cient protocols have limited scope of applications and general protocols are not extremely wire e ff i cient
  45. MQTT Looking at MQTT data message it can be seen

    how the wire overhead is linear into the length of the topic name. This is a big issue since the topic name is a UTF-8 encoded string which tends to be several tens of bytes. The minimal wire-overhead is thus 6 bytes plus the length of the topic name. To give you a concrete example, if you have an MQTT topic called /com/ acme/mysystem/devicekind/id, this would add 32 bytes | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---+---+---+---+---+---+---+---+ | messagetype | DF| QoS | R | +---------------+---+-------+---+ ~ Remaining Length (1-4 bytes) ~ +-------------------------------+ | Topic Name Length MSB | +---+---+---+---+---+---+---+---+ | Topic Name Length LSB | +---+---+---+---+---+---+---+---+ | | ~ Topic Name ~ | | +---+---+---+---+---+---+---+---+ | Message ID MSB | +---+---+---+---+---+---+---+---+ | Message ID LSB | +---+---+---+---+---+---+---+---+ | | ~ Payload ~ | | +---+---+---+---+---+---+---+---+
  46. DDS Looking at the DDS data message it can be

    seen how the wire overhead overhead of 56 bytes assuming that no inline QoS are sent 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'R' | 'T' | 'P' | 'S' | +---------------+---------------+---------------+---------------+ | ProtocolVersion version | VendorId vendorId | +---------------+---------------+---------------+---------------+ | | + + | GuidPrefix guidPrefix | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO_TS |X|X|X|X|X|X|0|E| octetsToNextHeader | +---------------+---------------+---------------+---------------+ | | + Timestamp timestamp + | | +---------------+---------------+---------------+---------------+ | DATA |X|X|X|X|X|D|Q|E| octetsToNextHeader | +---------------+---------------+---------------+---------------+ | Flags extraFlags | octetsToInlineQos | +---------------+---------------+---------------+---------------+ | EntityId readerId | +---------------+---------------+---------------+---------------+ | EntityId writerId | +---------------+---------------+---------------+---------------+ | | + SequenceNumber writerSN + | | +---------------+---------------+---------------+---------------+ ~ ParameterList inlineQos [only if Q==1] ~ +---------------+---------------+---------------+---------------+ ~ SerializedPayload serializedPayload [only if D==1 || K==1] ~ +---------------+---------------+---------------+---------------+
  47. Zenoh Zenoh sends frames, where a frame may contain multiple

    messages. This allows to pack e ff i ciently multiple data messages – or other protocol messages – and further improve the wire e ff i ciency. If we look at the Zenoh’s data message, reported in its minimal wire overhead is 3 bytes. Taking into account the 2 bytes added by the frame we get to a total of 5 bytes overhead – when sending a single data message. If Zenoh is able to batch N messages, then the wire overhead becomes (3N + 2)/N which tends to 3 bytes fairly quickly in N. +-------+------+------+- ... -+ | FRAME | DATA | DATA | ... | +-------+------+------+- ... -+ 7 6 5 4 3 2 1 0 +---------------+ | DATA HEADER | 1 byte +---------------+ ~ RESOURCE ~ 1+ bytes +---------------+ ~ Payload LEN ~ 1+ bytes +---------------+ ~ Payload ~ +---------------+
  48. Transparent Compression Another feature that is available in Zenoh to

    reduce wire-overhead and in general the amount of data sent is transparent compression
  49. Key Points Based on the analysis above, we can deduce

    that Zenoh is ~20x more wire e ffi cient than DDS For MQTT, it depends on the length of the topic name. In the given example, which represents an average topic length, Zenoh is 10x more wire e ffi cient.
  50. What does it means? The relative di ff erence is

    extremely important in spite of the small absolute value Consider applications that send data 24x7x365 like robots, cars, IoT devices, etc., then you can see that over time the di ff erences really diverge As an example sending let’s assume a data sample sent every minute, over a year DDS will have a wire overhead of 1.8 Gbps while Zenoh of 157Mb. Now assume that this data is produced by an o ff shore sensor, usually in these cases they pay $8 per MB of data. As a result the cost for sending the DDS protocol data would be $14400 while for Zenoh only $1256
  51. Topological Impact Routing e ffi ciency is really about taking

    the shortest path to the destination. You may wonder why a protocol should not do that. Unfortunately protocols that impose topological constraints, such as hub- and-spoke architectures, su ff er from this problem. As DDS doesn’run across the Internet nor on low-power networks or extremely constrained hardware, we’ll not analyze its routing e ff i ciency as it is not applicable in most of the use cases that are relevant.
  52. A Needle in the Haystack In order to estimate the

    routing e ff i ciency, it would be good to know the number of Watts used per Km This information is impossible to gather. We have asked researchers across institutions… But nothing… It is not to be known!
  53. Wrapping Up Communication protocols can have a major impact on

    energy consumption There are three dimensions in e ff i ciency, wire, computational and topological — all have to be minimised Zenoh provides today probably the best way of controlling/ reducing energy consumption
  54. Provisioning, Management, Monitoring Zenoh provides you with a technological solution

    for building cloud-to-micro-controller systems Yet, you have to provision, manage and monitor the Zenoh infrastructure yourself But perhaps this is not the best way for you to use your time… is it? Router Router Brokered Routed Router Router Router Client Client Mesh Peer Peer Peer Peer Peer Router Client Client Client Client Router Router Client Clique Peer Peer Peer Peer Client Router Infrastructure
  55. Welcome out of the cave, my friend. It's a bit

    colder out here, but the stars are just beautiful. — Plato Zetta Leverages Zenoh to uni fi es communication, storage and computation from the cloud to the micro-controller Integrates seamlessly with mainstream protocols and data-bases It is extremely time, space and energy e ffi cient
  56. Lorem ipsum dolor sit amet Cloud Independent Zetta can work

    with any cloud, AWS, Azure, Linode, etc., as well as on premises Thus you can use your favourite cloud provider or mix and match as you wish
  57. Cloud to Device Zetta provides you with a single point

    of control to provision, manage and monitor the infrastructure on the cloud to thing continuum Communication is end-to-end secured and infrastructure running on premises is custom generated/ con fi gured to allow zero-touch provisioning Cloud Edge On Premise
  58. Zetta (Z) Z-PaaS. Zetta Platform as a Service supporting multi-

    cloud developments, public/private clouds and able to manage on-premise Z-Routers Z-Router. Zetta’s Zenoh router. Can be used stand- alone or integrated with Z-PaaS Z-Connectors. Connectors to protocols, e.g., DDS, MQTT, etc., and Data Bases, e.g. RocksDB, In fl uxDB, etc. Z-Tools. A rich set of tools supporting monitoring, management, administration, debugging, etc. Z-API. Programming API for a variety of programming languages and targets, e.g., Python, C/C++, Rust, Arduino, etc. Z-PaaS Z-Router Z-Connectors Z-Tools Z-API
  59. Robotics Automatically provision infrastructure spanning from the cloud your premises,

    e.g., a factory Provision the ROS/ROS2 Zenoh plugin and you are ready to tele-operate and let your Robots e ffi ciently communicate at any scale and from anywhere on the network Cloud Factory
  60. Scaling MQTT with Zetta With Zetta you can provision Zenoh’s

    MQTT plugin anywhere on the continuum Zenoh routes communication between MQTT brokers Additionally, you can interact with MQTT application via Zenoh native applications or any other protocol for which a plug-in is supported Cloud Edge On Prem
  61. ROS is the most adopted open-source robotics framework worldwide It’s

    the “Linux" for robotics Many packages available ROS: The Linux of Robotics
  62. The RMW enables communication between di ff erent components of

    a robotics systems Inside a robot or between robots/the control room The ROS Middleware
  63. All the tier 1 RMW implementations use DDS But DDS

    is not always adapted to all scenarios or easy to use, e.g. with wireless networks… The Need of a RMW Alternate
  64. Main ROS 2 targets are in/outdoor mobile robots It is

    fundamental to operate well over wireless networks (e.g. WiFi, 4G/5G) RMW Alternate The survey
  65. DDS is complex, hard to con fi gure, and hindering

    ROS2 adoption User Feedback DDS drawbacks
  66. Some users simply want Zenoh — no frills! Simplicity is

    key High performance is attractive for robotics User Feedback Zenoh simplicity
  67. Multi-connectivity support is a looked-after feature, not only WiFi/4G/5G but

    also 3rd-party techs It solves users’ pain-points User Feedback Zenoh connectivity
  68. 2023-09 ROS 2 RMW alternate Abstract........................................................................................................................................ 1 User Challenges with

    DDS..........................................................................................................2 DDS has a fully-connected graph of participants.....................................................................2 DDS uses UDP multicast for discovery................................................................................... 3 DDS can have difficulty transferring large data....................................................................... 3 DDS can struggle on some WiFi networks.............................................................................. 4 DDS tends to have complex tuning parameters...................................................................... 4 Vendor specific non-standard DDS extensions....................................................................... 4 Next Steps............................................................................................................................... 5 Requirements gathering............................................................................................................. 5 User Survey............................................................................................................................. 5 Demographics..............................................................................................................6 Technical Data............................................................................................................. 6 Alternative middleware options.................................................................................... 8 Requirements.......................................................................................................................... 9 Comparative analysis of currently available middlewares.................................................... 11 Complete list of investigated middlewares.......................................................................11 Performance.................................................................................................................... 13 Middlewares X Requirements................................................................................................13 Conclusion................................................................................................................................. 14 Appendix A.................................................................................................................................15 Abstract The ROS MiddleWare interface (RMW) is an abstraction layer that allows ROS 2 to swap out its underlying communication mechanism (middleware) at both compile time and runtime. All current Tier 1 implementations of RMW are based on DDS. At the time that this solution was chosen, it met many of the initial requirements. Over the last 8 years of use, based on user feedback a number of problems have been identified, including: RMW alternate The report It presents a thorough analysis of DDS challenges, survey results, and middleware alternatives It is very insightful, well written, and deeply argumented
  69. DDS challenges The DDS stack works well when it is

    carefully tuned and operated on a well- managed network […] The main goal is to create an RMW alternative that has a great “out of the box” experience for users
  70. Zenoh: The RMW Alternate Zenoh has been selected as the

    fi rst non-DDS protocol to be natively supported in ROS2 Intrinsic is already implementing Zenoh RMW as the major contribution for next ROS2 release
  71. Zenoh for talking with any robot and application TCP, TLS,

    UDP, QUIC, etc. Serial, SHM, BLE, CAN, etc. WiFi, 4G, 5G, etc. Microcontrollers Fleet of Robots Edge and Cloud Single Robot
  72. Zenoh-Pico on autonomous submarines Integrated in Bristlemouth: an open hardware

    interface for all marine sensing systems Submarine vessels
  73. R2X for 5G drones doing remote inspections Connectivity for Fleet

    and Swarm Management Zenoh bridge ROS2 Drones
  74. uProtocol GM uProtocol selected Zenoh as the fi rst protocol

    top be integrated This is already visible on the public uProtocol repository
  75. AUTOSAR Classic Integrated Zenoh as part of AUTOSAR Classic as

    a solution for microcontrollers Support native (Zenoh) connectivity with AUTOSAR Adaptive with Cyclone DDS based ARA::COM
  76. Zenoh The Zenoh team is innovating at fast pace The

    community is growing swiftly and expanding across Robotics, Automotive, IoT & More Growing awareness around the advantages provided by Zenoh Help us spreading the word!
  77. Brave. Visionary. Dependable. ZettaScale is an extremely innovative company, which

    has dared challenging the status quo in distributed computing ZettaScale has a proven track record of being an extremely loyal and dependable partner We have been taken as the example of an ideal partner by key companies such as THALES and Fujitsu. Our customers know that they can always rely on us! The world belongs to those who dare to dream