Rebranding (#112)

Author: pavel-kirienko

README.md

@@ -1,9 +1,9 @@
-# UAVCAN specification
+# Cyphal specification
 
-[![CI](https://github.com/UAVCAN/specification/actions/workflows/build.yml/badge.svg)](https://github.com/UAVCAN/specification/actions)
-[![Forum](https://img.shields.io/discourse/https/forum.uavcan.org/users.svg)](https://forum.uavcan.org)
+[![CI](https://github.com/OpenCyphal/specification/actions/workflows/build.yml/badge.svg)](https://github.com/OpenCyphal/specification/actions)
+[![Forum](https://img.shields.io/discourse/https/forum.opencyphal.org/users.svg)](https://forum.opencyphal.org)
 
-The sources of the UAVCAN specification and other related documents are contained here.
+The sources of the Cyphal specification and other related documents are contained here.
 
 When cloning this repository, don't forget to initialize the Git submodules:
 `git submodule update --init --recursive`.
@@ -15,7 +15,7 @@ When cloning this repository, don't forget to initialize the Git submodules:
 Follow the Zubax LaTeX guide: <https://kb.zubax.com/x/IYEh>.
 **Do not edit the document without the spell checker.**
 
-Write in American English <sub>*(don't look at me, I'm trying my best)*</sub>.
+Write in American English.
 
 Critical definitions (behaviors, constraints, assumptions, etc.) shall be written in the main body of the document.
 Optional content (clarifications, examples, elaborations) is placed either into footnotes or into blue remark boxes

compile.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 
-SRC=UAVCAN_Specification
+SRC=Cyphal_Specification
 
 # https://tex.stackexchange.com/a/52994/132781
 export max_print_line=1000

dsdl

@@ -179,4 +179,4 @@ TSWLatexianTemp*
 
 # Outputs
 *-converted-to.*
-UAVCAN_Specification.pdf
+Cyphal_Specification.pdf

specification/.gitignore

@@ -1,9 +1,9 @@
 % !TEX root
 %
-% Copyright (c) 2018-2019  UAVCAN Development Team
+% Copyright (c) 2018-2019  OpenCyphal
 %
 
-\documentclass{uavcandoc}
+\documentclass{cyphaldoc}
 
 \usepackage{multirow}
 \usepackage{tabularx}
@@ -48,12 +48,10 @@
 
 \section*{Overview}
 
-UAVCAN is an open lightweight protocol designed for reliable intravehicular communication
-in aerospace and robotic applications over robust transports.
-It is created to address the challenge of deterministic on-board data exchange
-between systems and components of advanced intelligent vehicles.
-
-The name UAVCAN stands for \emph{Uncomplicated Application-level Vehicular Communication And Networking}.
+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.
 
 Features:
 
@@ -76,7 +74,7 @@ \section*{Overview}
 
 \section*{License}
 
-UAVCAN is a standard open to everyone, and it will always remain this way.
+Cyphal is a standard open to everyone, and it will always remain this way.
 No authorization or approval of any kind is necessary for its implementation, distribution, or use.
 
 % The following statement looks a bit archaic, but it is the recommended form according to

specification/UAVCAN_Specification.tex specification/Cyphal_Specification.texspecification/UAVCAN_Specification.tex renamed to specification/Cyphal_Specification.tex

@@ -3,22 +3,22 @@ \chapter{Application layer}\label{sec:application}
 Previous chapters of this specification define a set of basic concepts that are the foundation of the protocol:
 they allow one to define data types and exchange data objects over the bus in a robust and deterministic manner.
 This chapter is focused on higher-level concepts: rules, conventions, and standard functions that are to be
-respected by applications utilizing UAVCAN to maximize cross-vendor compatibility, avoid ambiguities, and
+respected by applications utilizing Cyphal to maximize cross-vendor compatibility, avoid ambiguities, and
 prevent some common design pitfalls.
 
 The rules, conventions, and standard functions defined in this chapter are designed to be an acceptable middle
 ground for any sensible aerospace or robotic system.
-UAVCAN favors no particular domain or kind of system among targeted applications.
+Cyphal favors no particular domain or kind of system among targeted applications.
 
 \begin{itemize}
     \item Section~\ref{sec:application_requirements} contains a set of mandatory rules that shall be
-    followed by all UAVCAN implementations.
+    followed by all Cyphal implementations.
 
     \item Section~\ref{sec:application_conventions} contains a set of conventions and recommendations that
     are not mandatory to follow. Every deviation, however, should be justified and well-documented.
 
     \item Section~\ref{sec:application_functions} contains a full list of high-level functions defined on
-    top of UAVCAN. Formal specification of such functions is provided in the DSDL data type definition files that
+    top of Cyphal. Formal specification of such functions is provided in the DSDL data type definition files that
     those functions are based on (see chapter~\ref{sec:sdt}).
 \end{itemize}
 

specification/application/application.tex

@@ -1,7 +1,7 @@
 \section{Application-level conventions}\label{sec:application_conventions}
 
 This section describes a set of high-level conventions designed to enhance compatibility
-of applications leveraging UAVCAN.
+of applications leveraging Cyphal.
 The conventions described here are not mandatory to follow;
 however, every deviation should be justified and documented.
 
@@ -27,7 +27,7 @@ \subsection{Service latency}
 
 \subsection{Coordinate frames}
 
-UAVCAN follows the conventions that are widely accepted in relevant applications.
+Cyphal follows the conventions that are widely accepted in relevant applications.
 Adherence to the coordinate frame conventions described here maximizes compatibility and
 reduces the amount of computations for conversions between incompatible coordinate systems and
 representations.

specification/application/conventions.tex

@@ -1,28 +1,28 @@
 \section{Application-level functions}\label{sec:application_functions}
 
-This section documents the high-level functionality defined by UAVCAN.
+This section documents the high-level functionality defined by Cyphal.
 The common high-level functions defined by the specification span across different application domains.
 All of the functions defined in this section are optional (not mandatory to implement),
 except for the node heartbeat feature (section~\ref{sec:application_functions_heartbeat}),
-which is mandatory for all UAVCAN nodes.
+which is mandatory for all Cyphal nodes.
 
 The detailed specifications for each function are provided in the DSDL comments of the data type definitions
 they are built upon, whereas this section serves as a high-level overview and index.
 
 \subsection{Node initialization}
 
-UAVCAN does not require that nodes undergo any specific initialization upon connection to the bus ---
+Cyphal does not require that nodes undergo any specific initialization upon connection to the bus ---
 a node is free to begin functioning immediately once it is powered up.
 The operating mode of the node (such as initialization, normal operation, maintenance, and so on)
 is to be reflected via the mandatory heartbeat message described in section~\ref{sec:application_functions_heartbeat}.
 
 \subsection{Node heartbeat}\label{sec:application_functions_heartbeat}
 
-Every non-anonymous UAVCAN node shall report its status and presence by periodically publishing messages of type
+Every non-anonymous Cyphal node shall report its status and presence by periodically publishing messages of type
 \DSDLReference{uavcan.node.Heartbeat} at a fixed rate specified in the message definition using the fixed subject-ID.
 Anonymous nodes shall not publish to this subject.
 
-This is the only high-level protocol function that UAVCAN nodes are required to support.
+This is the only high-level protocol function that Cyphal nodes are required to support.
 All other data types and application-level functions are optional.
 
 \DSDL{uavcan.node.Heartbeat}
@@ -32,7 +32,7 @@ \subsection{Generic node information}
 The service \DSDLReference{uavcan.node.GetInfo} can be used to obtain generic information about the node,
 such as the structured name of the node (which includes the name of its vendor),
 a 128-bit globally unique identifier, the version information about its hardware and software,
-version of the UAVCAN specification implemented on the node, and the optional certificate of authenticity.
+version of the Cyphal specification implemented on the node, and the optional certificate of authenticity.
 
 While the service is, strictly speaking, optional, omitting its support is highly discouraged,
 since it is instrumental for network discovery, firmware update, and various maintenance and diagnostic needs.
@@ -52,7 +52,7 @@ \subsection{Bus data flow monitoring}
 
 \subsection{Network-wide time synchronization}
 
-UAVCAN provides a simple and robust method of time synchronization%
+Cyphal provides a simple and robust method of time synchronization%
 \footnote{The ability to accurately synchronize time between nodes is instrumental for building distributed
 real-time data processing systems such as various robotic applications, autopilots, autonomous driving solutions,
 and so on.} that is built upon the work
@@ -181,7 +181,7 @@ \subsection{Generic node commands}\label{sec:application_functions_generic_comma
 
 \subsection{Node software update}
 
-A simple software\footnote{Or firmware -- UAVCAN does not distinguish between the two.}
+A simple software\footnote{Or firmware -- Cyphal does not distinguish between the two.}
 update protocol is defined on top of the remote file system interface
 (section~\ref{sec:application_functions_file_system})
 and the generic node commands (section~\ref{sec:application_functions_generic_commands}).
@@ -201,9 +201,9 @@ \subsection{Node software update}
 
 \subsection{Register interface}\label{sec:application_functions_register}
 
-UAVCAN defines the concept of \emph{named register} -- a scalar, vector, or string value with an associated
-human-readable name that is stored on a UAVCAN node locally and is accessible via
-UAVCAN\footnote{And, possibly, other interfaces.} for reading and/or modification
+Cyphal defines the concept of \emph{named register} -- a scalar, vector, or string value with an associated
+human-readable name that is stored on a Cyphal node locally and is accessible via
+Cyphal\footnote{And, possibly, other interfaces.} for reading and/or modification
 by other nodes on the bus.
 
 Named registers are designed to serve the following purposes:
@@ -230,7 +230,7 @@ \subsection{Register interface}\label{sec:application_functions_register}
 Data types supported by the register protocol are defined in the nested data structure
 \DSDLReference{uavcan.register.Value}.
 
-The UAVCAN specification defines several standard naming patterns to facilitate cross-vendor compatibility
+The Cyphal specification defines several standard naming patterns to facilitate cross-vendor compatibility
 and provide a framework of common basic functionality.
 
 \DSDL{uavcan.register.* --index-only}
@@ -244,18 +244,18 @@ \subsection{Diagnostics and event logging}
 
 \subsection{Plug-and-play nodes}\label{sec:application_functions_pnp}
 
-Every UAVCAN node shall have a node-ID that is unique within the network (excepting anonymous nodes).
+Every Cyphal node shall have a node-ID that is unique within the network (excepting anonymous nodes).
 Normally, such identifiers are assigned by the network designer, integrator, some automatic external tool,
 or another entity that is external to the network.
 However, there exist circumstances where such manual assignment is either difficult or undesirable.
 
-Nodes that can join any UAVCAN network automatically without any prior manual configuration
+Nodes that can join any Cyphal network automatically without any prior manual configuration
 are called \emph{plug-and-play nodes} (or \emph{PnP nodes} for brevity).
 
 Plug-and-play nodes automatically obtain a node-ID and deduce all necessary parameters of the physical layer
 such as the bit rate.
 
-UAVCAN defines an automatic node-ID allocation protocol that is built on top of the data types defined in the
+Cyphal defines an automatic node-ID allocation protocol that is built on top of the data types defined in the
 namespace \DSDLReference{uavcan.pnp} (where \emph{pnp} stands for ``plug-and-play'')
 (see table~\ref{table:dsdl:uavcan.pnp}).
 The protocol is described in the documentation for the data type \DSDLReference{uavcan.pnp.NodeIDAllocationData}.
@@ -275,7 +275,7 @@ \subsection{Plug-and-play nodes}\label{sec:application_functions_pnp}
 \subsection{Internet/LAN forwarding interface}
 
 Data types defined in the namespace \DSDLReference{uavcan.internet} (see table~\ref{table:dsdl:uavcan.internet})
-are designed for establishing robust direct connectivity between local UAVCAN nodes and hosts on the Internet
+are designed for establishing robust direct connectivity between local Cyphal nodes and hosts on the Internet
 or on a local area network (LAN) using \emph{modem nodes}\footnote{%
       Usually such modem nodes are implemented using on-board cellular, radio frequency,
       or satellite communication hardware.
@@ -292,7 +292,7 @@ \subsection{Internet/LAN forwarding interface}
 \begin{remark}
     Some of the major applications for this feature are as follows:
     \begin{enumerate}
-        \item Direct telemetry transmission from UAVCAN nodes to a remote data collection server.
+        \item Direct telemetry transmission from Cyphal nodes to a remote data collection server.
         \item Implementation of remote API for on-board equipment (e.g., web interface).
         \item Reception of real-time correction data streams (e.g., RTCM RC-104)
               for precise positioning applications.
@@ -307,7 +307,7 @@ \subsection{Meta-transport}
 Data types defined in the namespace \DSDLReference{uavcan.metatransport}
 (see table~\ref{table:dsdl:uavcan.metatransport})
 are designed for tunneling transport frames\footnote{Section~\ref{sec:transport_model}.}
-over UAVCAN subjects,
-as well as logging UAVCAN traffic in the form of serialized UAVCAN message objects.
+over Cyphal subjects,
+as well as logging Cyphal traffic in the form of serialized Cyphal message objects.
 
 \DSDL{uavcan.metatransport.* --index-only}

specification/application/functions.tex

@@ -1,6 +1,6 @@
 \section{Application-level requirements}\label{sec:application_requirements}
 
-This section describes a set of high-level rules that shall be obeyed by all UAVCAN implementations.
+This section describes a set of high-level rules that shall be obeyed by all Cyphal implementations.
 
 \subsection{Port identifier distribution}
 
@@ -10,26 +10,26 @@ \subsection{Port identifier distribution}
 \begin{itemize}
     \item unregulated port identifiers that can be freely chosen by users and integrators (both fixed and non-fixed);
     \item regulated fixed identifiers for non-standard data type definitions
-          that are assigned by the UAVCAN maintainers for publicly released data types;
-    \item regulated identifiers of the standard data types that are an integral part of the UAVCAN specification.
+          that are assigned by the Cyphal maintainers for publicly released data types;
+    \item regulated identifiers of the standard data types that are an integral part of the Cyphal specification.
 \end{itemize}
 
 More information on the subject of data type regulation is provided in section~\ref{sec:basic_data_type_regulation}.
 
 The ranges are summarized in table~\ref{table:application_requirements_port_id_distribution}.
 The ranges may be expanded, but not contracted, in a future version of the document.
 
-\begin{UAVCANSimpleTable}{Port identifier distribution}{|l l X|}%
+\begin{CyphalSimpleTable}{Port identifier distribution}{|l l X|}%
     \label{table:application_requirements_port_id_distribution}
     Subject-ID      & Service-ID        & Purpose \\
     $[0, 6143]$     & $[0, 255]$        & Unregulated identifiers (both fixed and non-fixed). \\
     $[6144, 7167]$  & $[256, 383]$      & Non-standard fixed regulated identifiers (i.e., vendor-specific). \\
     $[7168, 8191]$  & $[384, 511]$      & Standard fixed regulated identifiers. \\
-\end{UAVCANSimpleTable}
+\end{CyphalSimpleTable}
 
 \subsection{Port compatibility}
 
-% https://github.com/UAVCAN/specification/pull/64#discussion_r357771739
+% https://github.com/OpenCyphal/specification/pull/64#discussion_r357771739
 
 The system integrator shall ensure that nodes participating in data exchange via a given port\footnote{%
     I.e., subject or service.
@@ -75,7 +75,9 @@ \subsection{Standard namespace}
 An overview of related concepts is provided in chapter~\ref{sec:dsdl}.
 
 This specification defines a set of standard regulated DSDL data types located under
-the root namespace named ``\verb"uavcan"'' (section~\ref{sec:sdt}).
+the root namespace named ``\verb"uavcan"''%
+\footnote{The standard root namespace is named \texttt{uavcan}, not \texttt{cyphal}, for historical reasons.}
+(section~\ref{sec:sdt}).
 
 Vendor-specific, user-specific, or any other data types not defined by this specification
 shall not be defined inside the standard root namespace\footnote{Custom data type definitions shall be located