content-column.html

<!---
   Main Content Column
  --->

<div id="cyphalInAction" class="carousel slide mx-n3 mx-md-0" data-ride="carousel" data-interval="8000">
  <div class="carousel-inner">
    <div class="carousel-item active">
      <img class="d-block w-100" src="/static/images/katla.aero.jpg" alt="Aircraft">
      <div class="carousel-caption">
        <p>Cyphal interfaces avionics and on-board computing systems in manned and unmanned aircraft</p>
        <p class="credits">Image by Katla Aero</p>
      </div>
    </div>
    <div class="carousel-item">
      <img class="d-block w-100" src="/static/images/revolve.jpg" alt="Robotics">
      <div class="carousel-caption">
        <p>Cyphal enables real-time distributed computing in bleeding-edge robotics</p>
        <p class="credits">Image by Revolve NTNU Trondheim</p>
      </div>
    </div>
    <div class="carousel-item">
      <img class="d-block w-100" src="/static/images/hitec.jpg" alt="COTS equipment">
      <div class="carousel-caption">
        <p>Cyphal is an open interoperability standard for off-the-shelf equipment</p>
        <p class="credits">Image by Hitec RCD</p>
      </div>
    </div>
    <div class="carousel-item">
      <img class="d-block w-100" src="/static/images/earthrise.jpg" alt="Spacecraft">
      <div class="carousel-caption">
        <p>Cyphal runs distributed avionics in modern spacecraft</p>
      </div>
    </div>
  </div>
  <a class="carousel-control-prev" href="#cyphalInAction" role="button" data-slide="prev">
    <span class="carousel-control-prev-icon" aria-hidden="true"></span>
    <span class="sr-only">Previous</span>
  </a>
  <a class="carousel-control-next" href="#cyphalInAction" role="button" data-slide="next">
    <span class="carousel-control-next-icon" aria-hidden="true"></span>
    <span class="sr-only">Next</span>
  </a>
</div>

<!-- -------------------------------------------------------------------------------------------------------------- -->
<h1 id="what" class="mt-4">What is Cyphal?</h1>
<p>
  Cyphal is an open technology for real-time intravehicular distributed computing and communication based on
  modern networking standards (Ethernet, CAN FD, etc.).
  It was created to address the challenge of on-board deterministic computing and data distribution in
  next-generation intelligent vehicles: manned and unmanned aircraft, spacecraft, robots, and cars.
</p>
<p>
  The underlying <a href="/specification" target="_blank">Cyphal Specification</a> is open to everyone,
  and it will always remain this way.
  No licensing or approval of any kind is necessary for its implementation, distribution, or use.
</p>
<p>
  Cyphal was known as UAVCAN
  <a href="https://forum.opencyphal.org/t/uavcan-v1-is-now-cyphal/1622" target="_blank">before 2022</a>.
</p>
<h2>Features</h2>
<ul>
  <li>
    Designed for <b>complex, high-integrity, real-time vehicular computing</b> systems.
  </li>
  <li>
    <b>Publish/subscribe</b> and <b>request/response (RPC)</b> exchange semantics.
  </li>
  <li>
    Specialized interface description language provides <b>rich zero-cost interface abstractions</b>
    and facilitates <b>service-oriented design</b>.
  </li>
  <li>
    <b>Lightweight</b> &mdash; implementable from scratch in ca. 1000 logical lines of code; cheap to verify and validate.
  </li>
  <li>
    <b>Peer-to-peer network</b> &mdash; no bus master, no single point of failure.
  </li>
  <li>
    <b>Modular redundancy</b> for fault-tolerant systems with automatic fail-over.
  </li>
  <li>
    <b>Different transport-layer protocols</b> (Ethernet, CAN, etc.), including heterogeneous transport redundancy.
  </li>
  <li>
    <b>High-quality open source reference implementations</b> are freely available under the MIT license.
  </li>
</ul>

<!-- -------------------------------------------------------------------------------------------------------------- -->
<h1 id="how">How do I use Cyphal?</h1>
<p>
  First, read the <a href="/guide" target="_blank">Guide</a>. To learn the technical details, read the
  <a href="/specification" target="_blank">Specification</a>. Familiarize yourself with the
  <a href="https://github.com/OpenCyphal/public_regulated_data_types">regulated DSDL repository</a>.
  If you have questions or feedback, bring them to the <a href="https://forum.opencyphal.org">forum</a>.
</p>
<p>
  The OpenCyphal project provides MIT-licensed implementations of the Cyphal technology
  (other implementations of the Cyphal stack are available from third parties):
</p>
<div class="table-responsive">
  <table class="table table-borderless table-sm w-unset table-nowrap">
    <thead class="thead-light">
      <tr>
        <th scope="col">Library</th>
        <th scope="col">Transports</th>
        <th scope="col">Language</th>
        <th scope="col">Applications</th>
        <th scope="col">Status</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td><a href="https://github.com/OpenCyphal/libcanard">LibCANard</a></td>
        <td>Cyphal/CAN</td>
        <td>C</td>
        <td>Embedded (low-level)</td>
        <td>Stable</td>
      </tr>
      <tr>
        <td><a href="https://github.com/OpenCyphal/libudpard">LibUDPard</a></td>
        <td>Cyphal/UDP (Ethernet)</td>
        <td>C</td>
        <td>Embedded (low-level)</td>
        <td>Stable</td>
      </tr>
      <tr>
        <td><a href="https://github.com/OpenCyphal-Garage/libcyphal">LibCyphal</a></td>
        <td>Cyphal/UDP, Cyphal/CAN</td>
        <td>C++</td>
        <td>Embedded (higher-level), application</td>
        <td>Beta</td>
      </tr>
      <tr>
        <td><a href="https://github.com/OpenCyphal/pycyphal">PyCyphal</a></td>
        <td>Cyphal/CAN, Cyphal/UDP, Cyphal/serial</td>
        <td>Python</td>
        <td>HMI, application, scripting</td>
        <td>Stable</td>
      </tr>
    </tbody>
  </table>
</div>
<p>
  These open source tools will help you design, develop, and maintain your Cyphal-based application:
</p>
<ul>
  <li>
    <a href="https://github.com/OpenCyphal/nunavut">Nunavut</a> &mdash;
    a Python library and a <abbr title="command-line interface">CLI</abbr> tool
    for transcompiling DSDL definitions into C/C++/Python/etc.
    A web-GUI is available at <a href="https://nunaweb.opencyphal.org">nunaweb.opencyphal.org</a>.
  </li>
  <li>
    <a href="https://github.com/OpenCyphal/yakut">Yakut</a> &mdash;
    a simple <abbr title="command-line interface">CLI</abbr> tool for diagnostic and management of Cyphal networks.
  </li>
  <li>
    <a href="https://github.com/OpenCyphal/yukon">Yukon</a> &mdash;
    a rich GUI tool for observing, debugging, and interacting with a Cyphal bus.
  </li>
</ul>
<p>
  Please <a href="https://forum.opencyphal.org/t/766" target="_blank">reference Cyphal</a>
  in scientific or technical publications.
</p>

<!-- -------------------------------------------------------------------------------------------------------------- -->
<h1 id="why">Why do I need Cyphal?</h1>
<p>
  Modern vehicles are becoming increasingly complex as they implement advanced
  autonomy and safety capabilities.
  Most of the complexity is concentrated around the on-board software which largely defines the
  functional capabilities of the vehicle, yielding the concept of a <q>software-defined vehicle</q>.
  This is especially true for unmanned transport.
</p>
<p>
  Holistic approaches to the design of the on-board vehicular intelligence (or any sophisticated system in general)
  are complicated by the limitations of the human mind, so <em>distribution</em> is applied widely,
  where the resulting complex system is composed of subsystems and components
  whose lesser complexity is hidden behind well-defined abstract interfaces.
  While distributed computing is not a new concept, its application for vehicular intelligence
  may be hindered by the requirements of functional safety and determinism.
</p>
<p>
  The high intrinsic complexity of existing distributed computing technologies is due to a wide range of
  supported usage scenarios and types of interaction, only a small part of which is relevant for the
  application area of interest to us.
  We propose that this statement is true even for specialized prior art technologies (like DDS, ROS, SOME/IP).
  Careful rethinking of the basic principles and core requirements of the data distribution platform
  allowed us to achieve a more balanced trade-off between its intrinsic complexity
  (and, as a result, the cost of verification and validation)
  and its ability to express powerful abstractions
  (and, therefore, allowing the designer to implement more complex behaviors cheaply).
</p>
<p>
  Cyphal is a response to the unmet demand for a distributed computing technology that would allow the designer
  to hide the complexity of the components of the on-board intelligence behind well-formalized network services
  while not compromising on functional safety and the costs of verification and validation.
  Its design rests on the following core values:
</p>
<p>
  <i class="fas fa-head-side-virus"></i>
  <b>Simplicity</b> is paramount for high-integrity and safety-critical systems as it reduces the verification
  and validation efforts.
  The complexity of Cyphal scales together with its application: unsophisticated components (nodes) of the distributed
  computing system may implement the protocol in less than a thousand lines of code from scratch.
  The only mandatory application-level function that shall be supported by all implementations is the
  Heartbeat message;
  the broader spectrum of optional protocol capabilities remains at the disposal of the implementer, if needed.
</p>
<p>
  <i class="fas fa-cubes"></i>
  <b>High-level abstractions:</b>
  Cyphal allows the designer to construct robust service-oriented interfaces between components of the distributed
  computing system, taking into account fault-tolerance and real-time constraints.
  The definitions of such interfaces focus solely on the needs of the application and delegate
  impertinent lower-level details to the protocol
  (network state machines, distributed state management, data serialization, etc.).
  Cyphal provides a specialized domain-specific language for this purpose titled
  <abbr title="Data Structure Description Language">DSDL</abbr>.
</p>
<p>
  <i class="fas fa-shield-alt"></i>
  <b>Fault-tolerance:</b>
  Cyphal is a decentralized peer-to-peer network with built-in support for modular redundancy.
  Under certain reasonable assumptions,
  the protocol is compatible with unreliable networks where packet loss is possible due to short-term
  destructive environmental influences.
</p>
<p>
  <i class="fas fa-cogs"></i>
  <b>Determinism:</b>
  Cyphal is designed to satisfy the requirements of real-time deterministic embedded systems.
  The resource ceiling (time, memory) is always trivially predictable and provable.
</p>
<p>
  To meet these values, Cyphal makes reasonable assumptions about the system.
  The first such assumption is that the
  <a href="https://en.wikipedia.org/wiki/Network_calculus">service curve</a>
  of the underlying transport network is well-characterized,
  and the probability of packet loss in the absence of adverse influences from the outside environment
  (e.g., electromagnetic interference or faulty connector) is zero.
  The latter means that losses cannot arise as a result of processes occurring within the network,
  such as a queue overflow, but short-term disturbances caused by external factors such as electromagnetic
  interference may occur.
  Packet losses caused by such external disturbances are
  <a href="https://forum.opencyphal.org/t/idempotent-interfaces-and-deterministic-data-loss-mitigation/643"
  >mitigated by tunable duplication of transfers</a>.
  This assumption is valid for deterministic on-board networks.
</p>
<p>
  Cyphal is nearly <a href="https://en.wikipedia.org/wiki/Stateless_protocol">stateless</a> &mdash;
  the protocol is designed to drastically minimize the shared state compared to prior art technologies.
  As a result, the state space of the distributed system is reduced;
  its analysis, implementation, and testing are simplified.
  Participants of the distributed system make virtually no assumptions about the state of their collaborators.
  Traditional pub-sub frameworks define an explicit subscription establishment procedure where the subscriber
  informs the publisher of its interest in specific data (SOME/IP, DDS, virtually all MQ*, etc.),
  whereas in Cyphal the publisher blindly sends messages to the network,
  allowing interested agents to accept or ignore them.
</p>
<p>
  The latter circumstance would have hampered scalability if not for the extensive reliance on
  hardware packet filtering and pattern matching.
  Other commonly used protocols (with notable exclusion of AFDX, ARINC 664) often overlook the fact
  that modern high-speed networking hardware provides powerful means of automatic traffic policing
  (e.g., Ethernet NICs, switches, CAN controllers, etc).
  Reasonable exploitation of this fact
  <a href="https://forum.opencyphal.org/t/324">enables
  radical simplification</a>
  of the transport layer.
</p>
<p>
  The absence of explicitly synchronized states between collaborators
  (between a publisher and a subscriber or between an RPC client and its server)
  allows a newly joined network participant to start performing its tasks immediately,
  without any mandatory registration procedures, service discovery, etc.
  This is important when analyzing failure scenarios where a critical device is briefly shut down
  and then reconnected to the network
  (e.g., due to a power surge, lightning strike, software or hardware defect, etc.).
</p>
<p>
  Another assumption is that the distributed computing system is typically configured statically.
  First, the configuration of vehicular systems is rarely subject to radical changes in the field,
  which allows Cyphal to avoid the complexity and failure case analysis of dynamic reconfiguration in most cases.
  This, however, does not mean that dynamic field reconfiguration (e.g., plug-and-play devices) is not supported
  (it is useful in research and some limited subset of production systems),
  but it means that dynamic reconfiguration capabilities belong to the optional parts of the protocol
  which can be omitted to simplify the validation and verification of safety-critical applications.
</p>
<p>
  Second, Cyphal always provides a well-defined guaranteed resource ceiling for any part of the system
  at the design stage.
  Data types defined using the previously mentioned DSDL language always have an upper limit on the size
  of any variable-length data field,
  which means that the worst-case data transfer latency, worst-case (de-)serialization time,
  and, in general, the worst-case processing time can be determined statically.
  A practical example is shown below:
</p>
<pre>
<code class="comment"># A generic displacement amplitude spectrum representation. Documentation is omitted for brevity.</code>
<code class="type">uavcan.si.unit.frequency.Scalar.1.0</code> <code>frequency_step</code>
<code class="type">float32[<=1024]</code> <code>peak_abs_amplitude</code>  <code class="comment"># [meter]</code>
<code class="comment"># Observe that the array length is bounded. It is not possible to define an unbounded data type.</code>
<code class="type">@assert</code> <code>_offset_.max == 8 * (4 + 2 + 1024 * 4)</code> <code class="comment"># Validate the layout.</code>
</pre>
<p>
  At the transport layer, bounded resource utilization and timely data processing are facilitated by
  explicit upper bounds on all protocol resources.
  For instance, the maximum number of publish-subscribe channels in the system is limited
  (the limit, however, is expected to be sufficient for any application), as well as the number of network nodes.
  The specification discusses different approaches to implementing the transport layer
  with an assessment of their asymptotic complexity.
</p>
<p>
  At the application layer, the user defines custom network services and data types
  (using the DSDL domain-specific language) for use in pub-sub or RPC links.
  For common tasks (like diagnostics, file transfer, logging, configuration management, etc.)
  there is no need to design custom network services because the corresponding definitions are
  provided by the standard library of network services.
</p>
<p>
  Cyphal is also intended to serve as a foundation for narrowly specialized
  domain-specific application-layer standards
  (like standard USB classes, CANopen profiles, DDS FACE, etc.).
</p>
<p class="text-center">
  <img src="/static/images/scope_of_cyphal.svg" width="750px" alt="Scope of Cyphal">
</p>
<p>
  Adopting Cyphal might seem like a little paradigm shift for an engineer experienced with prior art solutions,
  but our experience and understanding of the field give us confidence that it as a necessary step
  to adapt to the growing sophistication of modern software-defined vehicles.
</p>

<!-- -------------------------------------------------------------------------------------------------------------- -->
<!-- TODO consortium is temporarily hidden
<h1 id="who">Who is behind Cyphal?</h1>
<p>
  The OpenCyphal Consortium is a non-profit organization established to support, promote and standardize
  the technology, and expand the Cyphal ecosystem.
  Any entity that leverages Cyphal is welcome to join the organization to take part in shaping the
  future of the technology and stay ahead of the curve.
  The following benefits are available only to the members of the Consortium:
</p>
<ul>
  <li>
    Use the official Cyphal Conformity Mark with hardware and software products that pass the conformance test.
  </li>
  <li>
    Include vendor-specific or domain-specific data types and network service definitions to the official
    public regulated data types repository.
  </li>
  <li>
    Directly influence the future of the technology.
  </li>
</ul>
<p>
  <a href="/consortium">Learn more and apply to become a member</a>.
</p>
-->