Slide 1

Slide 1 text

CEO / CTO angelo@zettascale.tech Angelo Corsaro, PhD ZettaScale The world belongs to those who dare to dream

Slide 2

Slide 2 text

Company Overview

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Zettlers Values Zettlers are Technology Knights and live embracing the Seven Knightly Virtues of Courage, Justice, Mercy, Generosity, Faith, Nobility and Hope.

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Some of the world most demanding customers and challenging systems trust ZettaScale and its Technologies ZettaScale Customers

Slide 7

Slide 7 text

Locations ZettaScale HQ is in Europe, R&D organised around technology centre of excellence in France — (Grand Paris, Plateau de Saclay) — and Netherlands respectively

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Current Investors

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

What’s The Problem?

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

A Cross Industry Problem Robotics Automotive IoT / Edge

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

The Solution

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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”

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Zenoh identi fi ed as the most appropriate protocol for V2X applications for autonomous and assisted driving ITU

Slide 26

Slide 26 text

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?

Slide 27

Slide 27 text

Zenoh used for V2X communication in the Indy Autonomous Challenge This blog describes the the problem it solved!

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

OpenRobotics carried an independent evaluation on Zenoh and how it could improve ROS2 communications — A new hope OpenRobotics in 2022

Slide 31

Slide 31 text

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)

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Zenoh Overview

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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 …

Slide 36

Slide 36 text

Runs Everywhere OS Linux, MacOS, Windows, QNX (alpha) Embedded Targets Arduino, ESP32, mbed, Zephyr, and many more Automotive Targets AUTOSAR Classic (microSAR)

Slide 37

Slide 37 text

Any Topology Peer-to-peer Clique and mesh topologies Mesh Peer Peer Peer Peer Peer Clique Peer Peer Peer Peer

Slide 38

Slide 38 text

Any Topology Peer-to-peer Clique and mesh topologies Client Client Mesh Peer Peer Peer Peer Peer Clique Peer Peer Peer Peer Client

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Topology in Perspective

Slide 42

Slide 42 text

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/**

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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.

Slide 48

Slide 48 text

Lorem ipsum dolor sit amet Easy to Use

Slide 49

Slide 49 text

Router Storage Plugins Protocol Plugins MAIN MEMORY FILE SYSTEM Runtime Plugins Zenoh Flow RocksDB Plug-Ins

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Energy Efficiency

Slide 52

Slide 52 text

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.

Slide 53

Slide 53 text

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.

Slide 54

Slide 54 text

Computational Efficiency

Slide 55

Slide 55 text

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.

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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)

Slide 58

Slide 58 text

Wire Efficiency

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

DDS vs MQTT vs Zenoh

Slide 61

Slide 61 text

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 ~ | | +---+---+---+---+---+---+---+---+

Slide 62

Slide 62 text

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] ~ +---------------+---------------+---------------+---------------+

Slide 63

Slide 63 text

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 ~ +---------------+

Slide 64

Slide 64 text

Transparent Compression Another feature that is available in Zenoh to reduce wire-overhead and in general the amount of data sent is transparent compression

Slide 65

Slide 65 text

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.

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

Routing Efficiency

Slide 68

Slide 68 text

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.

Slide 69

Slide 69 text

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!

Slide 70

Slide 70 text

Qualitative Reasoning MQTT Pub Sub Pub Sub

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

Zetta Platform

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

Zetta (Z) The Cloud to Device Continuum Platform

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

Router Storage Plugins Protocol Plugins MAIN MEMORY FILE SYSTEM Runtime Plugins Zenoh Flow RocksDB Plug-Ins

Slide 80

Slide 80 text

Lorem ipsum dolor sit amet

Slide 81

Slide 81 text

Lorem ipsum dolor sit amet

Slide 82

Slide 82 text

Lorem ipsum dolor sit amet

Slide 83

Slide 83 text

Lorem ipsum dolor sit amet

Slide 84

Slide 84 text

Lorem ipsum dolor sit amet

Slide 85

Slide 85 text

Sample Use Cases

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

Market Adoption

Slide 89

Slide 89 text

Robotics

Slide 90

Slide 90 text

ROS is the most adopted open-source robotics framework worldwide It’s the “Linux" for robotics Many packages available ROS: The Linux of Robotics

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

DDS is complex, hard to con fi gure, and hindering ROS2 adoption User Feedback DDS drawbacks

Slide 95

Slide 95 text

Some users simply want Zenoh — no frills! Simplicity is key High performance is attractive for robotics User Feedback Zenoh simplicity

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

ROS 2 saviour? User Feedback Zenoh superhero?

Slide 98

Slide 98 text

User feedback Zenoh the most voted

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

Middleware comparative study…

Slide 102

Slide 102 text

No content

Slide 103

Slide 103 text

No content

Slide 104

Slide 104 text

No content

Slide 105

Slide 105 text

No content

Slide 106

Slide 106 text

No content

Slide 107

Slide 107 text

No content

Slide 108

Slide 108 text

No content

Slide 109

Slide 109 text

No content

Slide 110

Slide 110 text

No content

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

Zenoh on the field

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

Zenoh-Pico on autonomous submarines Integrated in Bristlemouth: an open hardware interface for all marine sensing systems Submarine vessels

Slide 115

Slide 115 text

Zenoh used for R2X communication on their remote mining machines Zenoh bridge DDS Heavy mining

Slide 116

Slide 116 text

R2X for 5G drones doing remote inspections Connectivity for Fleet and Swarm Management Zenoh bridge ROS2 Drones

Slide 117

Slide 117 text

Zenoh used for R2X communication on their Wide Area Network services Zenoh bridge ROS2 Logistics

Slide 118

Slide 118 text

No content

Slide 119

Slide 119 text

Automotive

Slide 120

Slide 120 text

Eclipse SDV Zenoh selected as one of the communication middleware in addition to MQTT

Slide 121

Slide 121 text

uProtocol GM uProtocol selected Zenoh as the fi rst protocol top be integrated This is already visible on the public uProtocol repository

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

OEM Adoption of Zenoh both on ECU as well as MCU

Slide 124

Slide 124 text

In Summary

Slide 125

Slide 125 text

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!

Slide 126

Slide 126 text

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