RTOSアプリケーションIoT MCU能力推定

RTOSアプリケーションのIoT MCUにはどの程度のハードウェア能力が必要か?
この答を IEEE標準RTOS のμT-Kernelプログラミングコンテスト対象評価ボードから考察しました。

RTOSコンテスト評価ボード
RTOSコンテスト評価ボード

RTOSコンテスト対象評価ボード

MCUベンダ大手4社:インフィニティ、STマイクロ、NXP、ルネサス協賛のRTOSプログラミングコンテストが開催中です。RTOSは、IoT MCU世界標準のμT-Kernel 3.0利用がコンテスト条件です(関連投稿:前投稿)。

但し4社評価ボードは、μT-Kernel以外にもFreeRTOSやAzure RTOSでも動作可能です。そこで、これら評価ボードスペックを分析すると、RTOSアプリケーションのIoT MCUに、どの程度のMCUハードウェア能力が必要か、その目安が判ると思います。

コンテスト対象評価ボードは、ベンダ4社評価ボードと英BBC開発micro:bit、合わせて5種です。

インフィニティ:KIT_XMC72_EVK
STマイクロ:Nucleo_H723ZG
NXP:MCX N94x評価ボード(1月4日現在Coming Soon)
ルネサス:EK-RA8M1
BBC:micro:bit

評価ボードMCUコアとROM/RAM量

各評価ボードは、どれもARM Cortex-M系コアを用いています。

インフィニティとSTマイクロは、ハイパフォーマンスMCU Cortex-M7、NXPは、Trust Zone搭載MCU Cortex-M33、ルネサスは、AI/ML性能向上のArm Helium搭載MCU Cortex-M85、BBC開発micro:bitは、ベーシックなMCU Cortex-M4です。

評価ボードのCortex-Mコアと最高動作速度、ROM/RAM量が下表です。

ベンダ Cortex-Mコア/速度 ROM(KB) RAM(KB)
インフィニティ M7/350MHz 8192 1024
STマイクロ M7/550MHz 1024 564
NXP M33/150MHz 1024 1024
ルネサス M85/480MHz 2049 1024
BBC M4/64MHz 512 128

BBC開発micro:bitは、他に比べスペックが劣っています。
これは、μT-Kernel 3.0学習教材用でコスト最優先のためと思います。

ベンダ4社評価ボードは、RTOSコンテスト参加ハードウェアなので、どれも汎用RTOSアプリケーション開発ができるハズです。コンテストエントリー時に、応募者が第3希望まで評価ボードを選べます。

IDEはRTOSもベアメタルも同じ

ベンダ4社は、ベアメタル開発用の統合開発環境:IDEを利用し、FreeRTOSやAzure RTOS開発環境を提供中です。

例えば、STマイクロは、ベアメタル開発で使うSTM32CubeIDEに、ミドルウェアのAzure RTOS開発ツールを追加し、Azure RTOS開発環境を、ユーザ自身で構築します(関連投稿:STM32 Azure RTOS開発ツール拡充

現代的ユーザMCU開発の例(出展:The ST blog)
現代的ユーザMCU開発の例(出展:The ST blog)

コンテストは、μT-Kernel 3.0 RTOS開発です。筆者は、μT-Kernel 3.0をベンダ4社評価ボード上で動作させる作業、いわゆるポーティング処理は、把握していません。

しかし、本稿主題は、RTOS IoT MCUに必要なハードウェア能力の推定です。従って、評価ボードへのμT-Kernel 3.0ポーティングは、無視します。

一方、micro:bitは、μT-Kernel 3.0で動作するEclipse IDEが提供されます。従って、どなたでも直ぐにmicro:bit上でμT-Kernelを動かすことができます。この点も、教育用に適しています。

RTOS IoT MCUハードウェア能力推定

最初の表に戻り、RTOS IoT MCUに必要なハードウェア能力を推定します。

ベンダ Cortex-Mコア/速度 ROM(KB) RAM(KB)
インフィニティ M7/350MHz 8192 1024
STマイクロ M7/550MHz 1024 564
NXP M33/150MHz 1024 1024
ルネサス M85/480MHz 2049 1024
BBC M4/64MHz 512 128

先ず、MCUコア能力は、micro:bitスペックから最低でもCortex-M4以上、RTOSアプリケーションを実用的に開発するには、Flash ROMは1024KB以上が必要そうです。教育用micro:bitの512KBは、排除しました。

また、RTOSは、動作タスク数に比例し使用スタック量が急増します。これは、RTOSが実行タスクを別タスクへ切替える毎に、実行タスク変数やレジスタ等の状態をスタックにプッシュするためです。タスク再実行の際には、RTOSがスタックからポップし、実行前タスク状態へ戻します。

RTOSスタック動作(出展:ウィキペディア)
RTOSスタック動作(出展:ウィキペディア)

仮に、このRTOSポップ/プッシュに対してスタック量が不足した場合は、再現し難いバグになります。このバグを避けるには、必要十分な量のスタック領域が、RAM上に必要となります。スタック量を見積もるツールは、各社のIDEに付属しています。

表から、RTOSアプリケーション開発には、RAMは、最低でも512KB、安全側評価なら1024KB程度が必要そうです。

Summary:RTOS IoT MCUハードウェア能力

RTOSアプリケーションが動作するIoT MCUに必要なハードウェア能力を、μT-Kernelプログラミングコンテスト対象評価ボードから考察した目安が下記です。

MCUコア:ARM Cortex-M4以上、Flash ROM 1024KB以上、RAM 512KB以上

RTOSアプリケーション開発時には、MCUデバイスコストと発展性の検討が必要です。

機能拡張や横展開が期待できるRTOSアプリケーションなら、IDE付属スタック見積ツールを活用し、RAMに余裕があるデバイスが、効率的で安全な開発ができそうです。

Afterword:2024年もよろしくお願いします

日本時間の毎週金曜日、MCU話題を中心に、その開発環境のWindowsや比較対象にMPU/SBCなども混ぜながら、IoT MCU開発お役立ち情報を投稿します。

「開発スピードと成果」この2つを強く求められるのが、MCUに限らず開発者の宿命です。

激変MCU環境で背反するこの2つを両立する手段の1つが、MCUテンプレートだと筆者は考えています。開発初期立上げをスムースにし、全体像の視点を持ちつつ個々の機能追加もできるからです。
RTOS MCU開発も同様だと思います。

但し、全て自作するベアメタル開発と異なり、RTOSと協調動作するのがRTOS MCU開発です。RTOSを活かすMCUタスク作成や本稿のMCUハードウェア能力を、弊社RTOSテンプレートへ反映したいと考えております。

本年もどうぞよろしくお願いいたします。

FreeRTOS version 11.0.0は、マルチコアMCU動作が可能になりました。


ベアメタルかRTOS開発か?

弊社MCUテンプレートご購入者様から、ベアメタルかRTOS、どちらの開発が良いかについてご質問がありました。
ご質問者同意を得ましたので、筆者回答を一部修正、抜粋して示します。

Summary:クラウド接続=RTOS開発、スタンドアロン=ベアメタル開発

RTOS vs. BareMetal
RTOS vs. BareMetal

AWSやAzure RTOSなどのクラウドへ接続するMCUは、RTOS(FreeRTOS/Azure RTOS)開発が必須です。クラウド接続やセキュリティ確保に、専用RTOSライブラリ利用が必要だからです。また、大規模、複数開発者の場合も、RTOS開発が向いています。

スタンドアロン動作のMCUは、ベアメタル開発をお勧めします。MCU動作を全て開発者で管理・制御できるからです。

ベンダ提供サンプルコードとMCU評価ボードを活用すると、ベアメタル/RTOSどちらの開発でも、高品質・短期間で製品のプロトタイプ開発ができます。弊社MCUテンプレートは、サンプルコード活用プロトタイプ開発に適しています。

クラウド接続MCU:割込みベースRTOSタスク開発

AWS (Amazon Web Services)やAzure (Microsoft Azure Cloud Services)へ接続するMCUは、クラウド接続用に、FreeRTOSやAzure RTOS接続ライブラリの利用が前提条件です。また、高度なセキュリティ対策が求められますので、クラウド側提供セキュリティライブラリを使うことも求められます。

従って、クラウド接続MCUは、必然的にRTOS開発となります。

通信やセキュリティ以外の処理は、タクス(スレッドとも言うが、以下タスクと略)の開発が、ユーザ開発内容です。

タスクは、移植性が高い単位に機能分割し、割込みベースで作成します。複数タスクの割込み処理や優先順位を管理・処理するのが、RTOSの役目です。

RTOSが優先順位に基づいて個々のタスクをMCUに割当てることで、複数タスクの並列処理が進みます。シングルコアMCUの場合、一度に実行するタスクは1個です。従って、タスクは時分割処理です。分割タイミングが短く、しかも優先順位に基づいたタスク処理ですので、複数タスクが並列処理しているように見えます。

タスクは、別タスクのことを考慮せず独立性、移植性高く開発可能です。その代償として、RTOSが複数タスク間優先制御を行うセマフォ/ミューテックス/イベントフラグなど、また、タスク間通信を行うメッセージバッファ/メールボックスなどのRTOS独自機能を、開発タスクに組込む必要があります。

関連投稿:RTOS習得

移植性や独立性が高い開発済タスクは、ベアメタル比、ソフトウェア資産として他プロジェクトへもそのまま使えるメリットがあります。また、ソフトウェア規模が大きく、複数開発者で共同開発する時も、機能完全分離RTOS開発の方が優れると言われます。

スタンドアロンMCU:ポーリングベースベアメタル開発

RTOSが行う周辺回路の割込み処理や優先制御を、全てユーザが行うのがベアメタル開発です。

但し、デバッグや処理開発のし易さを考慮すると、ポーリングベース開発をお勧めします。

つまり、周辺回路の割込みフラグを、一旦、割込み処理待ちフラグへ置換え、この割込み処理待ちフラグをポーリングすることで処理を実行する方法です。割込み処理待ちフラグは、RAMへ展開されますので、開発処理もRAMフラグで制御でき、割込みを直接扱うよりも単体デバッグが容易になります。

ベアメタル開発は、単体デバッグ済みの複数処理を、MCU全体で上手く実行する制御部分も必要です。弊社ベアメタルMCUテンプレート英語版MCUテンプレートは、この制御部分を提供します。

サンプルコード活用プロトタイプ開発

サンプルコード活用プロトタイプ開発
サンプルコード活用プロトタイプ開発

RTOSはタスク、ベアメタルは周辺回路制御のソフトウェア開発が必要です。

但し、ベンダは、周辺回路制御の参考となるソフトウェアを、サンプルコードとしてMCU評価ボードと共に提供します。サンプルコードは、ベンダ専門家が開発した評価ボード動作確認済み高品質コードですので、これをユーザが利用しない手はありません。

現在サンプルコードは、ベアメタル用のものが殆どです。しかし、RTOSタスク開発へも応用できます。サンプルを上手く利用することで、0から開発するよりも、短時間でソフトウェア開発ができます。

また、評価ボードMCU周りの部品配置やアートワーク配線は、処理性能過不足時のMCU交換や耐ノイズ性が高いハードウェア開発の参考書になります。

MCU開発を高品質・短期間で行うには、サンプルコードとMCU評価ボードを活用し、製品プロトタイプ開発がお勧めです。プロトタイプから製品へフィードバックをかければ、より良い製品化が可能です。

Afterword:ベアメタル開発からRTOSへステップアップ

IoT MCU開発者スキルの階層構造
IoT MCU開発者スキルの階層構造

Windowsアプリ開発時は、Windows APIの利用は当たり前です。多くの解説書もあります。

IoT MCU開発時も、FreeRTOSやAzure RTOSが当然になると思います。ただMCU開発には解説書が少なく、その理解には基礎知識が必要です。基礎がグラつくと、その上の積み重ねは非常に困難です。

MCU開発の基礎は、ベアメタル開発です。IoT普及でRTOS MCU開発も増えます。IoTに向けてRTOSを勉強しようと考える方も多いと思います。その場合は、ベアメタル開発の何をRTOSが代行し、何が得られ、何を失うか、RTOSオーバーヘッドはどの程度かを考えながら学習すると、より効率的にRTOS習得ができます。

例えば、RTOS開発には、セマフォやミューテックスなどのベアメタル開発に無い多くのRTOS機能を新に学ぶ必要があります。しかし、よく使う機能は少数です。ご自分のベアメタル手法を代行するRTOS機能から学び始め、それでも足りない機能はRTOS側に用意されていますので、順次増やしながらタスクを開発して行くと良いと思います。

ソフトウェア開発は、AI Copilot出現で激変への過渡期です。数年後には、ライブラリ組み換え作業などへ開発が変わり、不足がちなMCU開発解説もAIが代行してくれるかもしれません。

そんな全能AI過渡期でも、ご自分自身で獲得した基礎の重要性は、変わらないと筆者は考えます。


過酷高温のMCU変化

最高気温が35°Cを超える猛暑日が多発しています。IoT MCU装置の動作環境も、過酷な高温になることもあるでしょう。

そこで、過酷な高温環境で、MCUの何が、どのように変わるかをソフトウェア開発者向けにまとめます。

Summary:限界温度以下のMCU運用必須

限界温度以下のMCU運用必須
限界温度以下のMCU運用必須

過酷な高温でMCUが動作すると、半導体MCU自体が部分的に破壊され、常温に復帰しても元に戻りません。その結果、MCU論理やアナログ処理の異常、消費電流過大/過少などの症状が現れることがあります。

ソフトウェア開発者が、これら見つけにくい症状をデバッグするのは困難です。フェールセーフ観点から、ADCでMCU心臓部温度をモニタし、限界温度まで十分な余裕のあるうちに動作停止などのMCU運用が必要でしょう。

参考資料

  1. Notes on RA6E1 Group High-Temperature Operation、2023年7月10日
  2. マイコンの仕様を超える条件で使ったら、何が起きる(前後編)、2022年8月12日、9月2日

RA6E1アプリケーションノート:Notes on RA6E1 Group High-Temperature Operationは、ルネサスRA6E1(Cortex-M33コア、IoT向きMCU)を使った8個のアプリケーションで、信頼性劣化を防ぐMCU心臓部限界温度の実験結果を示しています。

※本稿は、Tj:ジャンクション温度を、MCU心臓部温度と略記します。

何が起きる(前後編)は、STマイクロの技術資料です。高温、高湿、高電圧ストレスが、一般的なMCUに与える影響と、その可逆性(常温で正常に戻るかどうか)を詳しく説明しています。

過酷高温でMCUの何がどう変わるか

どちらの参考資料も、デバイス開発者向けとしては良く出来ています。

特に1は、具体的アプリケーションでの周囲温度(Ta:-40℃~105℃)とMCU動作時ジャンクション温度(Tj)の許容範囲を示しており、2の高温ストレス限界の具体例です。

しかし、ソフトウェア開発者にとっては、そのメカニズムよりも過酷高温動作の結果、MCUの何がどう変わるかをもっと端的に知りたいハズです。

過酷な高温でMCUが動作すると、半導体MCU自体が物理的、部分的に破壊され、常温に復帰しても元に戻りません。その結果、論理処理やアナログ処理の異常、消費電流過大/過少などの症状が現れることがあります。これらは、常に現れる症状ではないと筆者は思います。

ソフトウェア開発者が、通常のソフトウェアバグとは異なるこれら症状をデバッグするのは、困難です。

例えば、高温限界を超えたMCUと新品MCUとを並行動作し、たまに発生する異常症状から間接的に判断する程度でしょう。結局、新品MCUとの交換が必要です。

過酷高温環境のMCU動作がもたらす結果
過酷高温環境のMCU動作がもたらす結果

フェールセーフ

自動車は、制御系が異常を検出するとリンプモード(limp mode)、つまり、エンジン/モータやその他部品などの追加損傷をおさえつつ、最低限の走行で乗員を帰宅させるモードへ移行します。

MCU装置の場合は、先ず過酷な高温場所に設置しないこと、それでもやむを得ず限界高温に近づいた場合は、MCU破壊を避けるため動作停止などのフェールセーフが必要でしょう。

最近のMCUは、温度計を内蔵しています。ADCで自身の温度を測り、「限界温度前の十分な余裕あるうち」にフェールセーフ処理実行が可能です。

ディレーティング、10℃2倍則

高温状態で信頼性が劣化するのは、MCUだけではなく、抵抗、コンデンサ、基板などの装置デバイス全てに及びます。装置内で消費電力が最も大きいMCUに高温影響が顕著に表れ、その異常症状が他のデバイスに比べ検出し易いだけです。

そこで、多くのデバイスから構成される装置を安全に運用するには、各デバイス最大定格の50%以下で使うのが良いとされ、これをディレーティング(derating)と言います。

また、周囲温度が10℃上がると、材料寿命が半分になる10℃2倍則(10℃半減則)もあります。

これらを考慮すると、人間同様IoT MCU装置も、十分な余裕がある適温で運用してこそ本来の機能を発揮し、かつ、装置寿命も保てると言えます。適温とは、参考資料1 Table 4.1 No.3の最も厳しいTj≤85℃の50%、つまり45℃~50℃位でしょうか?

筆者は、Windowsタスクマネージャーのパフォーマンスモニタで、半導体CPU/GPU温度が50℃を超えると、処理負荷を減らすかシャットダウンするようPC運用を心がけています。



ニッポン固執Change

“Change before you have to” 、Jack Welch氏(米GE:CEO、1981年から2001年)の名言です。日本スマホメーカ破綻とRapidus記事、グローバル市場必須の日本製造業と技術者の今をJack Welch氏の名言から考えてみました。

Rapidus記事

Rapidusロゴ

2023年6月12日から始まった日経クロステック「半導体立国ニッポンの逆襲」、Rapidus特集記事の昨日までの目次です。

第1回:日本で先端半導体をつくるだって?! 突然の記者会見、6月12日
第2回:20年前にラピダスの原点、小池社長の苦い過去、6月13日
第3回:ラピダス設立に動いた経産省の青写真、6月14日
第4回:ラピダス設立に透ける米国の影、6月15日
第5回:IBMからの電話で始まったラピダスへの道、6月16日
第6回:難関とともに終わったラピダス設立会見、6月19日
第7回:ニッポン半導体再起動へ、3つのラストチャンス、6月20日
第8回:⽇本半導体復活戦略の出発点「熊本」、6月21日
第9回:経産省が⽬指す半導体復活への3ステップ、6月22日

毎日追記され、各2000文字前後の文字数です。気分転換や隙間時間に読むのに適した量ですので、是非ご自身でお読みください。

AI要約ではありませんが、筆者が昨日迄の全記事をまとめたのが下記です。

全体トーンは、経産省主導Beyond 2nmを目指す次世代半導体会社Rapidus成功に懐疑的。2030年市場規模100兆円達成には、人材確保・育成や製造・量産ノウハウなど課題クリア必須。過去の政府主導失敗経験を活かしたのは、半導体ユーザ製造業(トヨタ、NTT、Sonyなど)を加えた点。但し、政府700億円拠出に対し、ユーザ10億円以下で温度差あり。Rapidus成功の道は険しいが、半導体立国ニッポン最後で最大のチャンス。

関連投稿:Rapidus(ラピダス)

日本スマホメーカ破綻

中高年やデジタル弱者に人気のある「らくらくスマホ」(出展:FCNTサイト)
中高年やデジタル弱者に人気のある「らくらくスマホ」(出展:FCNTサイト)

デジタル弱者、特に中高年層に人気があり販売実績数も多い「らくらくスマートフォン」メーカのFCNTが、経営破綻しました。

破綻要因は、半導体不足による調達価格高騰、スマホ不況など色々あると思います。言えるのは、ニッポンに拘った製品は、日本市場Shrinkと共に消える可能性大と言うことです。もはや、日本市場だけで存続できる製造業はあるのでしょうか?

例えば、前章Rapidus出資のトヨタ、Sonyは、グローバル市場でも稼いでいます。NTTもKDDIとタッグを組んでIWON(Innovative Optical and Wireless Network)を研究開発し、狙いはワールドワイド通信キャリア市場です。

関連投稿:世界規模の宇宙センシングIOWN

つまり、日本製造業が生残るには、ニッポン国内の稼ぎだけでは少なすぎる訳です。この対策の1つが、かつてのライバルKDDIと共同で光電融合デバイスを開発するNTTの動きにも現れています。

民間企業だけでなく、人口減少が進む地方自治体でさえ、従来のやり方では破綻危機が予想されています。

Summary:Change Now

Change before you have to

日本製造業は、高性能、高品質、低価格なニッポン製品を世界中へ輸出、販売し稼いできました。この稼ぎ方は、製品性能を左右する高性能半導体や円安が前提です。円安は、逆に海外製半導体の購入には不利です。

※円安=輸出日本製品が、海外で比較的安く買える

Rapidusが、次世代半導体のニッポン製造に拘る理由は、円安・円高の為替相場に依存しない高性能半導体の国内安定・安価提供が目的だからです。

同様の動きは、欧州半導体法米国CHIPS法にも見られます。ローカライゼーション動向に見えますが、これら諸法に後押しされる欧米製造業は、元々グローバル市場が狙いの猛者たちです(←誉め言葉です)。

日本製造業と日本技術者が生残るには、Rapidus成功・失敗にかかわらず、グローバル市場への “Change before you have to” が今必要、と名言は警鐘を鳴らしていると思います。

Afterword:弊社Change

WordPressの本サイトは、多言語対応済みです。しかし、MCUテンプレートサイトは、日本語のみ、ここも多言語化したいと考えています。

それにしても、本稿投稿のきっかけになった、ガラパゴス携帯に続く人口比多数派中高年対応らくらくスマホ破綻、単にスマホ不況だけでは考えられません。日本≠弱者≠ビジネス切捨対象なら良いのですが…。
Change必要です!



IoT MCUスキル習得方法

MCU開発に英語は必須です。どうすれば英語を学習できるのか?について、良い記事を見つけましたので紹介します。

ツール前提の新しい英語学習方法

米国で生活して実感した「英語学習」のオワコン化、2023年5月11日、日経XTECH

要旨

  • 求められるのは、日本で学習できる英文法や英会話ではない
  • 世の中に出回る便利ツールを知り、それを使いこなす能力、技術進化を素直に受け入れる姿勢必須
  • 技術進化の急激な領域は、ツール進化を前提に新しい英語学習方法が必要

英語学習便利ツール

  • Google翻訳/Googleレンズ翻訳
  • YouTube日本語字幕
  • DeepL機械翻訳
  • Grammarly英文法チェック
  • ChatGPT AIヘルプ

実体験に基づいた迫力ある記事です。是非読んで、英語学習、MCU開発に活かしてください。

従来学習・習得方法の限界

暮らしに英語が必要なのは、昔から変わりません。むしろ、世界に於ける日本地盤低下に伴い、英語の重要性は、益々高まりつつあります。

しかし、英語の学習・習得方法は、旧態依然です。この旧態依然傾向は、日本教育界だけでなく年齢を重ねるにつれて強くなります。年と共に頑固になる傾向が人間にあるからです。

その結果、日本人は英語が苦手です。

さて、このオワコン化した日本の英語学習とMCU開発は、同じ状況です。

英語学習オワコン化と現状MCU開発は同じ状況
英語学習オワコン化と現状MCU開発は同じ状況

従来のベアメタル開発に集中できた時代は終わり、AI、セキュリティ、RTOSなど様々な新しい技術が開発に必要です。しかも、各新技術の進化、発展が激しいIoT MCU時代へ変わりつつあります。

従来の学習、習得方法では、新技術の進化、発展へ追随するのは、非効率です。但し現代は、非効率さを改善する新しいツールが必ず生まれます。

重要なのは、この新しいツールを知り、使い、ツール活用による新技術学習・習得の結果です。習得順番や従来方法へこだわっていると、世界のIoT MCU開発に遅れる状況になります。

Summary:IoT MCUスキル習得方法

学問に王道なし。

学びに基礎が重要なのは、どの時代でも変わりません。基礎が無いと、上層技術の積み重ねが困難だからです。MCUならベアメタル開発です。記事の英語で言えば、英文法や英会話でしょうか?

これら基礎は、基礎ゆえに不変で、いつでも学び直すことができます。

各種ツールを使い上層技術を経験した後で、基礎技術不足を感じた場合は、その時点で基礎を再学習しても遅くはありません。

王道の歩み方は、各種ツール利用で柔軟に変化しても良い訳です。

IoT MCU技術進化のスピードは、基礎だけでは立ち行かない状況になりつつあります。求められるのは、上層新技術対応ツールとツール利用能力、上層技術から基礎を俯瞰できる能力です。

俯瞰の結果、不足基礎技術の補強を行えば、ツール利用で得た新技術が、身に着いた本当のスキルに変わると思います。

関連投稿:AI MCU、新しいMCUソフトウェアハードウェアの学び方、MCU開発ChatGPTの使い方



情報の受け手と情報量

ChatGPT懸念の情報が多い昨今です。一方、ChatGPT期待情報もあります。8対2ぐらいの割合でしょうか?

これらChatGPT騒動を例に、情報の受け手と情報量について筆者の思うところを記載します。

Summary:ポイントは適切な受け手想定と情報量

受け手に伝わって、初めて情報と言えます。送り手は、信頼性を高めるため、付加資料や文献出所などの情報量を加えます。

意味ある情報と受け手が判断するには、送り手の「受け手感度の想定と適切な情報量」が大切です。送受双方の感度が上手く合致し、かつ、適切な情報量(ページ数)の時に、人のあいだに意味ある情報として伝わると思います。

注)本稿では、意識、観点、主観など個人判断の基準となる感性全般を「感度」と記述します。

開発依頼者へMCU情報開示する際は、依頼者感度を想定、適切な量の資料作成が必須
開発依頼者へMCU情報開示する際は、依頼者感度を想定、適切な量の資料作成が必須

この伝わり方は、MCU開発者と開発依頼者間でも同じです。

MCU開発者が、依頼者へ情報提供する際は、依頼者感度を想定し、何を、どの程度伝えるか、適切な量の資料を作成すべきと思います。

受け手への情報量

ChatGPT騒動の記事には、技術的な参考資料や文献出所を記事途中に多く掲載するものもあります。

しかし、受け手が、一度に理解できる情報量や集中できる時間は、有限です。実例や簡潔な説明の方が、忙しい受け手や素人には、判り易いのも事実です。受け手の感度を想定した「情報量(ページ数)は、内容と同じぐらい重要」です。

つまり、過多な情報量は、受け手の内容理解の妨げになることもある訳です。

例えば、上司への報告書。忙しい上司から「報告書は1枚以内で提出」と言われた方も多いと思います。ページ数が多いと、上司は、初めから読まないことを暗に示しています。

最終章の「AIで記事を要約する(β)」ボタンでAIが自動生成する要約は、この人間特性も十分認識したうえで、適切な量の要約を作成します。

情報過多は、受け手の内容理解の妨げとなる
情報過多は、受け手の内容理解の妨げとなる

ChatGPT懸念情報

  • ChatGPTの安易な利用は禁物、2023年5月9日、日経XTECH
  • ChatGPTに懸念の声(英原文)、CIO Dive、2023年5月1日、IT Media(和訳)

ネガティブな情報の方が、ポジティブな情報よりもネット拡散し易く、印象に残り易いのかもしれません。ChatGPTのような革新的技術、AI関連技術に関しては、ネガティブ情報が圧倒的に多い気がします。

記事の書き手=送り手は、読者=受け手に読んでもらうことが目的です。ネガティブ記事タイトルの方が、読者や閲覧数が多い場合は、当然、ネガティブ記事が増えます。

ChatGPT期待情報

  • ChatGPTで人はもっと創造的になる、2023年5月9日、日経ビジネス

最近は、「AIで記事を要約する(β)」ボタンがある記事が増えました(実例、最終章参)。このボタンをクリックすると、記事内容が判り易く、しかも、適切な情報量で要約されます。

また、関連投稿でMCU分野FSPについてBingで質問したところ、正確で適切量のAI回答が得られました。

上記の使い方では、ChatGPTやAIは有益だと思います。ChatGPTを使うことでより創造的な時間が得られるという日経ビジネス記事に、筆者は賛同します。

ChatGPT利用は個人判断

厚生労働省は、2023年3月13日以降、COVID-19対策マスク着用の考え方を個人判断へ変えました。

国家機関がわざわざ個人判断を指示すること自体、欧米人は、奇妙に感じると思います。日本人特有の同調意識、他人と同じ感度を指向するからです。

マスク着用同様、ChatGPT利用も個人判断とすべきと思います。

ChatGPTやAI利用は個人判断とすべき
ChatGPTやAI利用は個人判断とすべき

判断のための情報収集は必要ですが、主体は個人、自分です。先ず、自分、つまり受け手のChatGPTやAIの使い方や感度を決めた上で、巷に溢れるChatGPTの情報を取集しないと、書き手、送り手の意見に左右されるだけになります。

筆者は、IoT MCU開発に使えるか否かという感度でChatGPT情報を収集しその結果、不明確なIoT MCU用語の質問に、ChatGPT利用は使えると判断しました。

Afterword:Bard日本語対応開始

2023年5月11日、Googleは会話型AIサービス、Bardの日本語対応を開始しました。これで、メジャーブラウザ、Microsoft Edge BingとGoogle Chrome Bard共に日本語でのAI回答の利用が容易になりました。

AIが適切な情報量で記事を要約するボタン
AIが適切な情報量で記事を要約するボタン

上記開始記事内に「AIで記事を要約する(β)」ボタンもあります(一回のみボタン押下げ可能)。各自で試してみてください。

本稿Summary内容が、具体的にご理解頂けると思います。

なお、BingとBardのAI回答の違いについては、コチラの記事が参考になります。



新しいMCUハードウェアの学び方

新しくMCU開発を始める方も多い時節です。新人や新担当者が、効率的にMCUを学ぶ方法を示します。今週は、MCUハードウェア編です(MCUソフトウェア編が、前投稿)。

Summary:新しいMCUハードウェアの学び方

  1. ベンダMCU評価ボードのアートワーク、実装部品を学ぶ
  2. 知りたい用語は、ChatGPTから回答を得る
  3. MCUとセンサなどの周辺回路動作電圧差に注意
ベンダMCU評価ボードの教師活用
ベンダMCU評価ボードの教師活用

MCUハードウェア習得のコツは、ベンダ提供MCU評価ボードの教師活用です。

開発に適す評価ボードの回路図やアートワーク、BOM(Bill of Materials:実装部品表)など全ての情報を活用します。

最近のMCUは、数100MHzクラスの高速動作です。安定した高速動作を支えるのは、MCU周りの電源配線アートワーク、実装部品、評価ボード電源回路です。

自社MCUボード開発時は、MCU周りアートワーク、評価ボードと同じ部品、これらを自社MCUボードへ適用するのが基本です。評価ボードのアートワークや実装部品の意味を考えることで、実践的なMCUハードウェアが学べます。

注)新しい点は、ChatGPT利用の知識習得、評価ボード教師活用の2点です。
注)1.2.3.の詳細は、後述します。

MCU評価ボード教師活用

理屈は知っていても、その理屈を実際の製品基板へ「上手く反映させる」のが難しい。これは、ハードウェア開発にありがちです。

例えば、高速動作には、配線を太く短くしノイズ対策すべきだが、部品の大きさや故障交換も考慮すると、この配置にせざるを得ない等々です。

つまり、ハードウェア開発者が、様々な制約条件を優先度で総合設計した結果が、製品に現れます。

この総合設計結果は、ベンダMCU評価ボードでも同じです。ユーザが、MCUを評価するためのボードですから、ユーザがどのようにMCUを使っても正常動作することに重点を置いた設計結果です。

言い換えると、MCUを最高速で動かした次の瞬間に低電力動作、更に割込み発生で瞬時に最高速へ戻るなど、究極のMCU動作にも余裕で耐えられる配線アートワークや電源部品を選定し、評価ボードへ実装済みです。

これらノウハウを詰め込み製品化したベンダMCU評価ボードのハードウェアを、手本や教師(≒ベンチマーク)として利用しない手はありません。

但し、設計ノウハウが文章化されることは、殆どありません。従って、担当者は、評価ボードから設計ノウハウの中身、背景を考え、学ぶことが必要になります。

つまり、製品設計を見抜く洞察力が、ハードウェアスキル向上に必要です。

ハードウェア製品の中身、背景を見抜く洞察力
ハードウェア製品の中身、背景を見抜く洞察力

経験者アドバイスを、MCUソフトウェア編では期待しました。しかし、MCUハードウェアは、先ずは物言わぬ評価ボードを教師:ベンチマークとする学びをお勧めします。理由は、MCUハードウェアや実装部品の世代交代の速さです。

ベンダMCU評価ボードは、最新MCUは勿論、MCU性能を活かす実績ある最新部品を使っています。MCUハードウェアは、ベンチマークから直接学ぶ方が、効率的です。

経験者アドバイスを活用するのは、優先度による総合設計時です。ただ、総合設計ノウハウは、状況に応じて刻々と変わり、かつ、文章化し難い、つまり、直感のようなものであることも忘れないでください。たとえ経験者でも、第3者への直感伝授は、難しい事柄です。

ポイントは、以下です。

  • ベンダMCU評価ボードをベンチマークにすること
  • 効率的に知識を得ること
  • MCUハードウェア世代交代に注意すること

これらポイントの実現手段が、前章Summaryに示したChatGPT利用と評価ボード教師活用です。

以下、Summary 1.2.3の詳細を説明します。

1. MCU評価ボードアートワーク、実装部品の意味を学ぶ

新しいMCUハードウェアの学び方その1
新しいMCUハードウェアの学び方その1

低速デバイス同士は、接続さえ間違わなければ機能します。しかし、数100MHzクラスやRF(無線周波数)ハードウェアのデバイスは、違います。

最近のMCUは、この数100MHzクラスを優に超える動作周波数です。IoT MCUなら無線デバイスも実装します。これら高速デバイスの安定動作や、周囲にノイズをまき散らさない工夫として、デバイス間の配線アートワークと電源供給が重要です。

回路図は、デバイス間の接続(ネットリスト)を作成します。同じ接続でも、実際にデバイスを基板上へ配置、配線するPCBアートワークが、高速デバイス製品成功の決め手です。

ベンダMCU評価ボードは、回路図、アートワーク情報、BOMも提供します。但し、提供だけで肝心の解説などはありません。従って、これらから決め手を自分で抜き取り、学ぶことが必要です。

例えば、アートワークを眺めていると、なぜMCUのこの配線だけ太く短いのか、BOMからは、なぜこの部品だけ高品質なのか、など疑問が沸いてくるハズです。

疑問をそのままにせず、自分なりに意味を考え、答えを持った後に、ChatGPTを利用すれば、より深い洞察ができます。

2. ChatGPTで回答を得る

新しいMCUハードウェアの学び方その2
新しいMCUハードウェアの学び方その2

ハードウェア進化は、早く劇的です。その例が、PC CPUソケットです。CPUソケットは、同一でのハードウェア進化を誰もが望みますが、時にはソケットや周辺部品を全面変更してまで進化に対応します。

新製品MCUや、これを活かす部品の情報は、ネット収集が効率的です。AIは、これら最新情報を常に収集、分析しています。ChatGPTは、質問の最新回答を得るのに適しています。

ChatGPT回答には、間違いの可能性もあります(関連投稿)。それでも、AIによる最新で判り易い文章回答は、期待できます。

ChatGPT利用により、担当者は、いつでも気軽に質問ができます。この気軽さと効率的回答(最新知識)を得るメリットの方が、間違いの可能性よりもまさると思います。

3. MCUと周辺回路の電圧差

新しいMCUハードウェアの学び方その3
新しいMCUハードウェアの学び方その3

MCUは、今後さらに高速化します。製造プロセス微細化と、高性能、低消費電力、低価格MCUをユーザが求めるからです。

一方、MCUへ接続するセンサは、デジタルだけでなく、アナログも重要な技術です。AI搭載など、センサ高度化も話題の昨今ですが、製造プロセスや動作電圧もMCUほど進化し難い側面があります。

高速追求のMCUと、高機能追求のセンサや周辺回路の差は、動作電圧差として現れる可能性があります。

5Vトレラント端子のMCU、MCU-センサ間インタフェースデバイス、複数電圧の電源回路など、MCUとセンサなどの周辺回路接続には、注意が必要です。

Afterword:設計クオリティと洞察力向上

MCUハードウェア開発者は、COVID-19による半導体不足を経験しました。

ハードウェア開発者としては、機能別モジュール化、制御系MCU評価ボードのそのまま流用などの組合せを工夫する対策に加え、シミュレーションやテストプログラム(TP)利用なども対策になります。

どの対策も、ハードウェア設計クオリティ向上が目的です。

ハードウェア設計ノウハウは、直感の部分もあります。直感が正しいか否かを客観判断し、勘を磨くには、シミュレーションやTPが役に立ちます。実際の測定器を使わずに、シミュレーションやTPを使って仮想的に試すと、試行錯誤も容易です。

MCU統合開発環境(IDE)は、これらシミュレーションツールやTP(サンプルコード)の宝庫です。MCUハードウェア開発者もIDEを活用し、直感を磨いてください。

更に、ハードウェア洞察力を磨くには、アートワーク設計もお勧めします。

MCU周り、ADC周りだけでも良いので、実際にPCBアートワークを行うと、回路図では見えない高速デバイス製品化ポイントが判ります。最近のMCU/ADC/無線デバイスデータシートは、これらアートワークについて記載されたものも多いので参考になります。



新しいMCUソフトウェアの学び方

新しくMCU開発を始める方も多い時節です。新担当者が、効率的にMCUを学ぶ方法を示します。今週は、ソフトウェア編、次週がハードウェア編です。

Summary:新しいMCUソフトウェアの学び方

  1. 細かいことは後回し、MCU評価ボードで主要サンプルコードを動かし、全体像を知る
  2. 知りたいMCU用語は、ChatGPTから回答を得る
  3. サンプルコードをIDEで担当者なりに変更し、評価ボード動作変化を見る
chatGPT利用の新しいMCU学び方
chatGPT利用の新しいMCU学び方

MCUソフトウェア習得のコツは、ベンダ公式サンプルコードの活用です。

開発に適したMCU評価ボードを入手後、サンプルコード動作 ⇋ IDEコード修正。この繰返しとChatGPT利用で短期・効率的にMCUソフトウェアが学べます。

注)新しい点は、ChatGPT利用の知識習得、サンプルコードベンチマーク活用の2点です。
注)1.2.3.の詳細は、後述します。

MCUソフトウェア学び障壁を下げるポイント

筆者がMCU開発を始めた頃は、MCUと周辺ハードウェアを設計後、外注さんへ発注。ハードウェアが出来上がるまでに、分厚いMCUマニュアルと格闘しながらソフトウェアに着手。それもドライバから開発し、短期完成には超過残業必須、苦労しました(残業当然の時代、ムダ作業も多かった…)。

現在は、MCUベンダが様々な高品質開発ツールを提供します。また、説明不足のMCU用語は、マニュアル検索よりも、ChatGPTで短時間に回答が得られますので、学びに集中できます。

高品質開発ツールとは、評価ボードと公式サンプルコードのことです。これらをお手本(≒ベンチマーク)として活用しない手はありません。

つまり、サンプルコードで、担当者の開発内容を試しながらMCUソフトウェア学びを進めます。ベンチマークからの差分が明確なので、バグ混入少、最も新担当者を悩ますバグ対処も少なく学びが可能です。

必要なのは、経験者から担当者へのアドバイスです。

本来MCUは、広範囲なアプリケーション開発が可能です。サンプルコード数の多さが、これを示しています。そこで、経験者が、ターゲットとする評価ボードとサンプルコードを担当者へアドバイス、または、担当者が経験者や先輩にこれらを聞いて、効率的なベンチマーク活用MCU習得を行います。

アドバイスにより、担当者は、ムダを省き目的のMCU学びに直結したアプローチができます。

MCUソフトウェア学び障壁を下げる
MCUソフトウェア学び障壁を下げる

MCU習得の障壁が高いのは、なんでもできるMCU応用範囲の広さと、担当者の知識不足です。障壁の高さを下げるポイントが以下です。

  • 開発(習得)アプリケーションのターゲットを絞ること
  • 効率的に知識を得ること
  • 慣れないIDEバグ対処を少なくすること

これらポイント実現手段が、前章Summaryに示したChatGPT利用、ベンチマーク差分開発です。

以下、Summary 1.2.3の詳細を説明します。

1. MCUソフトウェア全体像を知る主要サンプルコード

新しいMCUソフトウェアの学び方その1
新しいMCUソフトウェアの学び方その1

MCUソフトウェア全体像は、初期設定と無限ループ処理です。処理内容は、周辺回路に応じて異なりますが、構造は、どれも同じでシンプルです。

担当者が、この全体像を未把握の場合、サンプルコードを単なるAPI羅列としてしか捉えられません。初期設定と無限ループに機能分離して捉えれば、サンプルコード理解度が向上します。

MCUには、多くのサンプルコードがありますが、全てが業務の開発アプリケーションに関連する訳ではありません。経験者が知恵を絞って、業務アプリに関連する主要サンプルコードを選定すれば、担当者もターゲットが絞れます。

担当者は、主要サンプルコードからMCUソフトウェア全体像がどれも同じことを学べます。

2. 回答を得るChatGPT

新しいMCUソフトウェアの学び方その2
新しいMCUソフトウェアの学び方その2

担当者にとって、詳細な説明が、判り易いとは限りません。

経験者と担当者が対面会話中ならば、相手の理解度は概ね把握できます。また、担当者が不明なことは、経験者へ質問するでしょう。

しかし、文章による説明は、一方通行です。

一方通行の説明量は、多ければ多い程、理解度が上がるとは限りません。かいつまんだ説明の方が、判り易い場合も多いと思います。

ChatGPT回答には、間違いの可能性もあります(関連投稿:前稿)。それでも、AIによる判り易い文章回答が期待できます。

ChatGPT利用で、担当者は、LINEアプリのようにいつでも気軽に質問できます。心理的負担が少なく、効率的に回答(知識)を得るメリットの方が、間違いの可能性よりも優れると思います。

3. IDEに慣れ、開発アプリケーションをイメージ

新しいMCUソフトウェアの学び方その3
新しいMCUソフトウェアの学び方その3

MCU開発では、統合開発環境(IDE)操作に慣れることが必須です。

評価ボードと適正なサンプルコードがあれば、即座にIDEが使えます。しかも、ビルドも成功します。担当者は、サンプルコードへ変更を加え、評価ボードの動作変化も観察できます。

仮にコード変更でビルド失敗しても、元へ戻せば成功します。変更とビルド成功を繰返すことで、IDE操作とバグ対処に慣れ、MCU学びと業務アプリ開発へ一歩近づけます。

その結果、業務関連アプリケーションのイメージも生まれます。現状と開発アプリの差分が明確になり、MCU開発者らしい残件の目標設定もできます。

Afterword:現状把握を困難にするムダ

サンプルコードだけで動作するMCUに対し、万人が100%解るサンプルコードの説明は、困難です。対象読者や記述量に合わせて調整せざるを得ないのが実情です。MCU説明が、読者に解り難い原因です。

新しいChatGPT利用で、書き手のMCU説明不足は、かなり改善できます。

経験が少ない開発者には、ムダは、現状把握や目標設定を困難にします。ムダを少なくするため、経験者や先輩は、担当者の主体性も尊重したアドバイスを心がけてください。

業務アプリケーション完成には、複数サンプルコードを結合し動作させることも必要です。その際には、弊社の各ベンダ対応MCUテンプレートがお役にたちます。ご活用ください。



MCU開発に適すChatGPTの使い方

人間の質問に対し、AIが自然な回答を生成するChatGPT
人間の質問に対し、AIが自然な回答を生成するChatGPT

ChatGPT(Chat Generative Pre-trained Transformer)は、米)OpenAIが2022年11月に公開したAIチャットポットのことで、「生成可能な事前学習済み変換器」という意味です。人間の質問に対し、AIが自然な回答を生成します(Wikipediaより)。

MCU開発に、ChatGPTをどう活かすかについて私見を示します。

要約:MCU開発に適すChatGPTの使い方

  1. ChatGPTはMCU説明不足内容への質問、回答に使える
  2. ChatGPTは常に進化し続けるAIツールだが、MCUプログラミング適用は時期尚早
  3. AIが人類能力を超える予想の2045年シンギュラリティ前後ならMCU開発へ一部使える可能性あり

MCU製品開発の成功には、知識と経験が必要です。知識獲得の効率的ツールとして、現状のChatGPTは使えると思います。但し、AI回答をMCUプログラミングへ適用するには、現在はAIが未成熟です。

AIが十分に成熟し、人類能力を超えるSingularity(シンギュラリティ:技術的特異点、2045年と予想)近辺になれば、MCU開発へも使えるツールになる可能性はあると思います。

但し、AIがシンギュラリティを迎えても、開発MCU製品の顧客要求とMCU結合チューニングは、人間MCU開発者の経験が必須です。

ブラウザ検索との違い

知識獲得方法は、ブラウザ検索が一般的です。ブラウザ検索とChatGPTの違いを端的に説明しているのが、コチラのCNET Japan記事の冒頭部分です。

ブラウザ検索は、キーワードを入力し、関連性が高いサイトをリスト出力します。MCU開発者は、各サイトを閲覧し、その結果、知識を得ます。

一方、ChatGPTは、質問内容を入力し、AIが質問内容を分析後、大量のサイト情報から最も相応しいと「AIが思う回答」を自動生成します。

つまり、MCU開発者が、色々なサイトを閲覧する手間を省いて所望知識が得られる訳です。但し、AI生成回答が正しいか否かは、判りません。

そこで、Microsoft Bingを使って、ルネサスFSP(Flexible Software Package)を質問した時のAI生成回答を示します。注)FSPは、前投稿参照。

Microsoft Bingを使ってFSPを質問したChatGPT回答例
Microsoft Bingを使ってFSPを質問したChatGPT回答例

結構、的を射た回答をしていると思います。また、詳細情報に、関連サイトリンクもありますので、AI回答の正確さを質問者が検証することも可能です。

さらに、AIが想定する追加質問例もあります。現在Bing質問数は、1日に2000の上限がありますが、ブラウザ検索よりも効率的に、MCU説明不足内容を質問でき、回答を得ることができます。

注)ブラウザ検索では、複数サイトから得る情報の多様性があります。この多様性をノイズと考えるか否か、筆者個人は、多様性あり&最終回答を自分で考える方を好みます。

ChatGPTとMicrosoft Bing、Google Bard

ChatGPTもバージョンアップし最新版GPT-4は、大量の文章、大量の高性能コンピューターチップを使う巨大AIモデルです。OpenAI)CEO:サム・アルトマン氏は、AIのさらなる発展に新しい開発手法が必要だと語っています。

最新GPT-4を無料で使えるのが、前章のMicrosoft Bing、待機リスト登録で使えるのがGoogle Bardです。Bardは、現在日本語非対応のようです。

前章CNET Japan記事に、BingとBardのAI回答の違いが分析されています。

MCUコーディングの適用

上手く質問すれば、ChatGPTから、AIコーディング回答が得られます。しかし、それをそのまま実開発へ使えるかについては、いずれのサイトも現在懐疑的です。

筆者も、同じ考えです。

特に、MCUプログラミング(コーディング)は、他のPCソフトウェア開発やクラウドソフトウェア開発に比べ地味で、MCU開発者も少数派です。

ChatGPT活用コーディングは、今後益々盛んになるでしょう。その結果、ネットに、多数派ソフトウェア開発者の成功/失敗事例が多く掲載されます。AIは、これら事例を学習します。

これら多数派の事例をAIが十分学習した後、我々少数派MCUソフトウェア開発へ適用しても遅くはないと思います。その理由が、次章です。

AIコーディング進化時のMCU開発者経験とスキル

AIコーティング進化時のMCU開発者経験とスキル
AIコーディング進化時のMCU開発者経験とスキル

仮にChatGPTが、そのままMCU開発に使えるコーディングを正確に出力したとします。実はこれは、現在のMCUベンダ提供のサンプルコードに相当します。

つまり、ChatGPTの進化を待つまでもなく、現在でも単機能の正確動作コードは得られる訳です。ここが、多数派ソフトウェア環境と、MCUソフトウェアの大きく異なる点です。

MCUソフトウェアは、単体動作サンプルコードを、ベンダが多数提供済みです。

MCUソフトウェア開発者は、これら単体サンプルコードを、顧客要求やMCU性能に見合うように複数組合せ、期間内に上手く動作するよう製品化するのが、主な業務内容です。

例えば、低コストで性能制約も多いMCUを使い、単体コードの優先度設定や割込み処理設定を行い、複数コードを結合動作させるチューニングです。IoT MCUならば、RTOS対応やセキュリティ関連がチューニングに加わり、さらに複雑化します。

チューニングの幅は、顧客要求や適用MCU、製品の展開予定などにより大きく変わります。MCU開発者には、これら変化に即応できる開発経験やスキルが求められます。

例えシンギュラリティになっても、開発MCUの製品化、顧客要求とMCU結合チューニングは、AI任せにはできない「人間MCU開発者の腕の見せ所」になると思います。

つまり、この腕を磨いて人間MCU開発者も進化しましょう、と筆者は言いたい訳です。



IOWN 1.0提供開始

IOWN展開(出展:NTTサイト)
IOWN展開(出展:NTTサイト)

ベストエフォートのインターネットに対し、NTT専用線による品質保証:ギャランティーサービスIOWN(Innovative Optical and Wireless Network:アイオン)1.0が2023年3月16日から開始されました。

個人利用には価格(100Gbps月額料金198万円、初期設備費3万円)が高すぎますが、2030年以降のIOWN4.0では、インターネット並みの料金で利用できるかもしれません。

IOWN対インターネット

インターネットは、多重共用ネットワークです。従って、多重されたトラフィックにより自分のデータ遅延揺らぎは不可避、さらに強固なセキュリティも必須です。

そのセキュリティ対策は、ユーザみずから行う必要があります。対して、専用線は、ネットワーク側が通信品質を保証するなどセキュリティレベルは高く、ユーザのセキュリティ対策は、インターネットに比べると楽になると思います。

問題は、利用価格です。

IOWN専用線では、共用インターネットでは困難な魅力的IOWNサービス(後述)が提供され、かつ、APNと光電融合デバイスにより価格を抑え、かつ、将来の限界を超える特徴、つまり、低遅延、大容量、低消費電力(後述)があります。

ユーザセキュリティ費用、万一のセキュリティリスクも含め、専用線IOWNと共用インターネット、どちらが安全、安心で利用価格が安いのか、費用対効果検討が必要だと思います。

IOWNサービス

IOWNで期待されるサービスの実証記事がコチラです。

ロボットや自動車の遠隔制御、遠隔医療、e-スポーツや遠隔地間を繋ぐ同時演奏会など、大容量で低遅延、揺らぎ無しのIOWNサービスが提供されます。

IOWN特徴=揺らぎ無し低遅延+大容量+低消費電力

NTT技術ジャーナル2023.1によると、IoTによるデータドリブン社会は、膨大なデータ量やデータ処理サーバの膨大な電力消費増大に対して、限界が来るそうです。

この課題にAPN(All Photonic Network)サービスと、光電融合デバイスをボード接続→チップ間→チップ内と融合度を上げ、さらに、このデバイスをサーバへも適用することで、大幅な使用電力削減が可能となります(本稿最初の図参)。

IOWN4.0の目標は、電力効率100倍、伝送容量125倍、エンドエンド遅延1/200です。

IOWN特徴(出展:NTTサイト)
IOWN特徴(出展:NTTサイト)

まとめ

2030年度以降のIOWN4.0とインターネットの利用価格がどの程度になるかは、今のところ不明です。

それでも、IOWN1.0の利用決定会社/組織の記事(2023年3月3日、EE Times)を見ると、既に多くの有力企業が参加しています。

揺らぎ無し低遅延大容量IOWNが、新しいIoTネットワークサービスを生み、メタバースを推進するのは確かだと思います。IoT MCU開発者も注目しておく必要があります。

関連投稿:世界規模の宇宙センシング次世代ネットワークIOWN