新しいプロジェクトを始めるたびに、ゼロから始めるような気分になります。しかし、最近のシステムでは、レジスタから始めて、自分のやり方で作業を進めることはほとんどありません。その代わり、SDKやベンダーのIDEにあるビルド済みのサンプルから始めることになります。これらは多くの場合、シリコンベンダーが提供する特定のハードウェアと結びついており、開発ボード上のペリフェラルと結びついています。評価用としては最適ですが、より大きなシステムを構築するためには、いろいろなものを重ね合わせる必要があります。Zephyrはクロスプラットフォームのリアルタイムオペレーティングシステム（RTOS）とエコシステムです。同じ基本コードを、さまざまな接続方式や処理チップセットに適用することができます。また、あとで作りたいカスタムハードウェアのための再ターゲットも簡単にできます。
自分のビジネスロジックや周辺機能を組み込めるように、すでにたくさんの例が用意されているプロジェクトベースから始めたらどうでしょうか？そこで登場するのが優れたテンプレートです！
目標とする設計要件
私の仕事の大半は、ある業界の問題を解決するために、アプリケーションに特化した設計を行うことです。例えば、自動車のODB-IIポートに接続して、車速などの診断を読み出すことができる車両追跡装置です。保険会社は加入者の保険料を下げるためにこのようなことをしたいと考えています。設計の核心は、多くのセンサを読み取り、その読み取り値をインターネットに送信することです。デバイスをコントロールしたい場合は、クラウドからデバイスにデータをプッシュバックする必要があります。
オープンソースのリファレンスデザインテンプレート
私が最近始める方法は、Zephyrの上に構築されたOpen Source Reference Design Templateから始めることです。実際、このテンプレートはつい最近オープンソース化されたばかりです。このテンプレートには、デバイスからクラウド、クラウドからデバイス、といった双方向のAPIがすべて組み込まれていますので、気になる部分だけ開発を始めることができます。このテンプレートですぐに使える最も重要な機能は、Over-the-Air updatesであり、これは、設計当日からリモートでファームウェアを更新できるということを意味します。私のファームウェアの設計において、確実なことが1つあるとすれば、最初のrevisionくらいではうまくいかないし、デバイスが私の実験机の上にあるということは、まだうまくいっていないと言うことです。
私の通常の作業手順は、app_work.cファイルから始めます。Zephyr Sensor Subsystemを使用して、ターゲットプロセッサに接続されたデバイスと通信することがよくあります。Golioth Air Quality Monitor (AQM) Reference Designのようなものには、さまざまな環境センサが含まれます。代表的なものは、Sensirion SPS30（粒子状物質センサ）、 Bosch BME280（温度・湿度・気圧センサ）、そしてSensirion SCD41（空気質センサ）です。
これらのセンサがZephyrのツリー内にあれば、この作業はさらに簡単になります。センサからデータを抽出するには、Zephyr内で数行のAPIを呼び出すことになります。RTOSは実際に、利用可能な特性のリストからフォーマットされたデータタイプを返します。Zephyrのエコシステムは、センサ分野のベンダー間でさえも、ある程度の標準化を導入し始めていますが、これは素晴らしいことです。私がセンサに求めるのは、とにかく気圧か温度です。
センサから読み取ったデータをフォーマットして、デバイスとクラウド間で同期する時系列データベースであるLightDB Streamに送ります。Zephyrはクラウドへの接続を簡素化してくれますので、私の場合はよくnRF9160を使ってセルラー接続を行っています。Golioth Zephyr SDKは、クラウド上のエンドポイントとの接続とネゴシエーション（通信の互換性確認）を担当します。私の視点では、同じ温度や圧力のデータがクラウド上に「表示」さ れ、REST APIからデータを抽出してダッシュボードに表示したり、独自のアプリに送信したりできます。つまり、その測定値を使って作業したいソフトウェアチームにデータを渡すのに役立ちます。前述の空気質の例では、ダッシュボードには以下のように表示されます。
センサのデータが送信されるようになったら、自分の開発に関連しそうな他の機能の検討を始めます。Golioth Settings Serviceを使ってフィールドに設定をプッシュし、app_settings.cでデバイス上の処理コードを設定することができます。あるいは、app_rpc.cのサブルーチンを実行する独自の関数（Remote Procedure Call）をデバイス上で作成し、クラウド上でその関数をトリガすることもできます（変数の受け渡しも含みます）。デバイス側のコードを更新して新しい機能を持たせる必要がある場合は、いつでもOver-the-Air updateサービスを利用して更新することができます。
異なるハードウェアに対する対応
Zephyrの強みは、様々なハードウェアをターゲットにしていることです。オープンソースのテンプレートでは、Aludelプラットフォーム（弊社のカスタムプラットフォーム）とnRF9160-DKをターゲットにしています。これはZephyrプロジェクトのboardsディレクトリで行われます。
Ostentusカバーボード上のeInkディスプレイにデータを渡したいので、独自のカスタムプラットフォームをターゲットにしています。しかし、私たちはまた、ユーザーがテンプレートとその後の設計を試すことができるようにしたいと考えています。たとえ「ゼロから」プロジェクトを始めるとしても、これはセルラーIoTアプリケーションの素晴らしい出発点となります。センサを選び、クラウドから制御できる機能を決め、開発を始めてください。1ヶ月ではなく1日でデモを立ち上げたいと思っているエンジニアにとって、この方法は最適だと思います。
長期メンテナンス
本当の利点の1つは、テンプレートが前進するにつれて、アプリケーション固有の設計も前進させることができることです。新しい機能がGoliothプラットフォームで利用可能になったり、Zephyr ベースのテンプレートに特化したりすると、それらの変更を自分の設計に取り入れることができます。例えば、デバイスのファームウェアのバージョンを報告する標準的な方法を、標準的な画面に追加しました。その変更がテンプレート上で利用可能になったので、私はその機能を取り入れるために特定のデザインを更新しました。
課題がない訳ではありません。サブシステムをこつこつと組み合わせるのとは対照的に、テンプレートから作業するということは、古いデザインをアップグレードするときにマージによる競合が発生する可能性があることを意味します。私は以前、Thingy91について、セルラーIoTを素早く試すためのバイナリを作成するプロジェクトについて書いたことがあります。それもこのテンプレートに基づいており、引き続き活用する必要があります。しかし、Zephyrのマニフェスト（プロジェクト管理ファイル）を使う利点は、クラウド側のAPIが同じである限り、コードが絶え間なくビルドされ続けることです。私たちはこのことについてよく話しますが、Zephyrのバージョンとサブシステムを呼び出すことが重要だと考えており、将来の開発者（「将来のあなた」であっても）がプロジェクトの上で開発する際に成功するように設定されています。
Zephyr に関するヘルプ
Zephyrのヘルプが必要な場合、GoliothはZephyrの無料トレーニングを提供しています。devicetree、RTOSの使い方、KConfigなどの基本を学び、Zephyrの開発を始める方法や、ZephyrとGoliothを使用して、デバイスをクラウドに直接（そして簡単に）接続する方法についても学べます。