Blogテーマ変更とMCU開発顧客満足

本Blogテーマを、今週~来週にかけて変更中です。期間中は、画面表示が乱れる可能性もありますがご容赦ください😌。Blogツール:WordPressにご興味が無い方は、最後の章:MCU開発顧客満足をお楽しみください。

オープンソースCMSのWordPressによるBlog投稿

Blogテーマ変更理由

本Blogは、WordPressというオープンソースCMS(Contents Management System)を使って投稿しています。テーマとは、Blog表示の見た目を変える、着せ替え洋服のようなものです。テーマ変更理由は、2つです。

  1. 約2年前に導入されたWordPressの新しいGutenbergエディタ対策
  2. 昨年後期から続くサイトマップトラブル対策

Gutenbergエディタ

従来のWordPress標準エディタは、Classicエディタと呼ばれ、Web版無償Microsoft Wordのようなものです。基本的な文章エディタ機能を提供し、使い方も簡単でした。これに対し、新しく標準となったGutenbergエディタは、ブロック単位の編集・加工を行うなど操作性や使い方が大きく変わりました。

※Gutenbergエディタは、15世紀に活版印刷技術を発明したヨハネス・グーテンベルクにちなんで命名されました。WordPressの記事投稿に際し、活版印刷登場ほどインパクトがあると言うことです。

旧Classicエディタを使い続けたい多くのブロガーのために、標準Gutenbergエディタを無効化し、Classicエディタを復活するプラグインが提供され、筆者もこれを使い続けてきました。

但し、Gutenbergエディタは、毎年改良され機能や使い方も進化、この進化系Gutenbergエディタ対応の新しいテーマも増えてきました。

xmlサイトマップ

xmlサイトマップは、GoogleやYahoo、Bingなどの検索エンジンへ、弊社Blogの投稿内容等を知らせる手段です。

原因不明ですが、昨年後半から投稿数は週一で増やしているにも係わらず、サイトマップの有効ページ数が減り続けています。検索エンジンにマップされなければ、投稿しても読者に発見されず苦労が報われません。

ネット情報によると、プラグイン間の相性など様々な原因がありえますが、解決しません。いわゆるPCとアプリケーションとの相性問題と同じようです。

そこで、1のGutenbergエディタ対策時に、新テーマ導入と同時にプラグインを変える/減らすなどして対処しようと考えました。

Blogテーマ変更結果

今回のBlogテーマ変更の結果、WordPressの新Gutenbergエディタは習得しました。

しかし残念ながら、サイトマップトラブルは、更に悪化しました。プラグイン相性だけでなく、新導入テーマにも関係している可能性もありますが、依然として原因不明です。

算定措置として、Gutenbergエディタと新テーマ利用へ変更し、追加プラグインは最小にします。サイトマップトラブルは、継続検討とします。

MCU開発顧客満足

MCU開発でも課題に対し期待する成果が得られない等は、筆者には日常茶飯事です。費やした時間やコストは、戻ってきませんが、実際にやってみなければ本当は判らない事だらけなのがMCU開発業務です。

MCU開発業務は、以下2点の配慮が必要です。

  1. スケジュール立案時は、マージンを織り込む
  2. 成果に直結しない結果でも、今後に活かす

※織り込んだマージンを使わず成果が出た時は、未消化マージンをリフレッシュ休暇に替えます😁。

今回の対策も、年末年始の予定でした。しかし、新テーマの多さやその理解に時間がかかり、結局マージンを使い果たし1月末実施、そして少ない成果となりました。顧客は、自分自身ですが顧客満足は低いです。

しかし、成果に直結しなくても得た(貴重な!?)結果もある訳です。これを今後に活かす事が、費やした時間やコストを無駄にしない唯一の策で、しかも長い目で見れば、顧客満足にも繋がると信じます😤。

MCU開発は、日々の努力が、即成果に結びつかなくても、将来必ず顧客を満足させる結果・スキルになると自分を信じて続ける心構えが重要です(日本では、周囲になかなか理解してもらえないと思いますが😭、欧米開発者は、これがあたりまえの文化でした)。

無線STM32WBと汎用STM32G4比較

STマイクロエレクトロニクスの近距離無線通信機能付きSTM32WB(Cortex-M4/64MHz)と、汎用メインストリームSTM32G4(Cortex-M4/170MHz)を比較します。

Bluetoothなどの超省電力無線通信は、IoTデバイスに好適です。無線機能付きSTM32WBのIoTアプリケーション開発方法を調査し、汎用STM32G4を使ったSTM32WBのIoTアプリケーション開発の可能性とメリットを検討しました。

ディアルコアSTM32WBとシングルコアSTM32G4

STM32WBとSTM32G4、どちらもARM Cortex-M4コアを持つMCUです。違いは、STM32WBが、無線処理専用Cortex-M0+コア/32MHz内蔵のディアルコアMCUという点です。

Cortex-M4とM0+コア間のアプリケーションは、プロセス間通信コントローラ(IPCC)によりノンブロックイングで割込み利用のメッセージ交換が可能です。IPCCは、コアをSleep/StopモードからRunモードへ復帰させることもできますので、両コアは別々に低消費電力動作ができます。

STM32WBシリーズの紹介スライドP2から抜粋したSTM32WBとSTM32G4の位置づけが下記です。ワイヤレスマイコンのSTM32WLとSTM32WBの違いは、WLはLoRaWANなど、WBはBluetoothなどのサポート無線規格が異なる点ですが、Cortex-M4とM0+のディアルコア構成は同じです。

STM32WBとSTM32G4の位置づけ(出典:STM32WBの紹介)
STM32WBとSTM32G4の位置づけ(出典:STM32WBの紹介)

無線コプロセッサ:Cortex-M0+コア

STM32WBのCortex-M0+コアは、Bluetooth 5、ZigBee、OpenThreadなど2.4GHz帯無線通信処理専用です。ユーザ(開発者)は、利用する無線規格(BLE⇋ZigBeeなどのブリッジも可能)を選択し、STマイクロエレクトロニクス開発の無線専用ファームウェアをCortex-M0+へダウンロードします。但し、このファームウェアに手を加えることはできません。

言い換えれば、Cortex-M0+側の無線処理はSTの動作保証付きで、ファームウェアバージョンアップなどのメインテナンスは必要ですが、ユーザ変更などは不必要、ブラックボックスとして扱える訳です。

つまり、見た目はディアルコアですが、STM32WBのCortex-M0+は無線コプロセサで、外付け無線モジュールと同等です。従って、ユーザが開発するSTM32WBのIoTアプリケーションは、シングルコアのSTM32G4と同じ手法で開発が可能です。

Bluetooth 5(BLE含む)とサンプルプログラム

STM32WBの無線規格は、Bluetooth5やZigBeeなど複数プロトコルをサポートしています。このうち、IoTセンサの少量データ収集アプリケーションに好適なBluetooth5とBLEの詳細は、Bluetooth Low Energyプロトコルの基礎知識に説明があります。BLEを利用するIoTセンサ・アプリケーションを開発する場合には、最低限必要となる知識です。

STM32WBには、開発環境STM32CubeWBP-NUCLEO-WB55評価ボードで動作する様々なBLEサンプルプログラムがあります。サンプルプログラムの解析やこれらを応用したIoTアプリケーション開発時、BLE基礎知識が役立ちます。

また、P-NUCLEO-WB55評価ボードとスマートフォンをBLE接続し動作するサンプルプログラムもあります。

FSU: Firmware Upgrade Services

ディアルコアSTM32WBのCortex-M4アプリケーション開発時は、Cortex-M0+ファームウェアも同時にFlashへ書込みます。この点が、シングルコアSTM32G4開発と異なる部分です。

このFlash書込みには、STM32CubeProgrammmerのコマンドライトツール(CLI)で提供されるFSU:Firmware Upgrade Servicesを使います(動画説明はコチラを参照してください)。

簡単に言うと、Cortex-M4とCortex-M0+でメモリ共有中のFlashへ、ユーザ開発Cortex-M4アプリケーションを書込む時に、同時に通信Cortex-M0+ファームウェアも更新する仕組みで、手順さえ守れば通常のSTM32CubeIDEを使ったシングルコアSTM32G4のFlash書込み同様簡単です。

Flash書込み後は、STM32G4と同じ方法でアプリケーションデバッグを行います。

無線通信機能付きディアルコアSTM32WBと汎用シングルコアSTM32G4比較結果

P-NUCLEO-WB55とNUCLEO-G474RE
STM32WB評価ボードP-NUCLEO-WB55(左)とSTM32G4評価ボードNUCLEO-G474RE(右)

本稿で示したSTM32WB関連情報は、昨年末に行われたSTマイクロエレクトロニクス日本語ウェビナー資料から抜粋したもので、STM32マイコン体験実習(Bluetooth®編)でオリジナル動画とスライドが公開中です。また、STM32WBトレーニング資料Cortex-M4トレーニング資料も参考にしました。

前章までで、無線通信機能付きディアルコアSTM32WBと汎用シングルコアSTM32G4を比較し、下記を得ました。

  • ディアルコアSTM32WBのCortex-M0+側は、通信コプロセサでブラックボックとして扱える。
  • 例えば、IoTセンサデータ収集などのCortex-M4側IoTアプリケーションを、HAL(Hardware Abstraction Layer)APIで開発すれば、通信部分は異なるがデータ収集部分はSTM32WBとSTM32G4で共通開発できる。
  • STM32WBとSTM32G4で異なる点は、評価ボードへのFlashプログラミングだが、手順は簡単。
  • STM32WBのFlashプログラミングで用いたSTM32CubeProgrammerは、STM32G4のRoot of Trustで用いたもので、STM32WBでもSTM32G4と同様のRoot if Trustを実現できる。

HAL APIはコチラの関連投稿などを、STM32G4のRoot of Trustはコチラの関連投稿を参照してください。

STM32WBのIoTアプリケーションを汎用STM32G4で開発

最初の図に示したCortex-M4動作最高周波数の64MHzと170MHz、デバイスFlash/RAM容量差に注意すれば、STM32WBのIoTアプリケーションを汎用STM32G4で開発することは、可能でメリットもあると思います。

前提条件として、HAL API開発であること、STM32WBのIoTアプリケーション用Flash/RAM容量が、無線通信コプロセサCortex-M0+が使っても十分残ること、無線通信の代用としてUSARTなどの有線通信を使うこと、などです。FreeRTOS利用が良い場合があるかもしれません。

無線コプロセサCortex-M0+使用容量は、かなり少なく(ウェビナーでは使用量が公表されましたが数値未取得)Cortex-M4 IoTアプリケーション用空き容量は十分あります。また、汎用STM32G4の方が高速動作のため開発制約条件も緩いです。無線では、通信断時のエラー処理検討が必要ですが、有線ですのでエラー処理なしで本来の通信処理は開発可能です。

つまり、STM32WBの無線通信エラー処理以外は、ほぼ全て汎用STM32G4で代用開発が可能です。

Cortex-M4クラスMCUは、どれも高速で大容量Flash/RAMを実装し高いポテンシャルを持っています。つまり、IoTプロトタイプ開発とその評価には、最適なデバイスです。

汎用STM32G4で代用開発済みアプリケーションをSTM32WB/STM32WLへ移植し、IoTプロトタイプ開発をスピードアップするメリットは、差分開発、つまりIoT特有機能の差分を開発ができることです。

ある程度MCU開発経験を持つ開発者が、従来MCU開発では少なかった無線通信や高度なIoTセキュリティなどのIoTアプリケーション特有の重点ポイントに注力でき、即座にIoTプロトタイプ開発(代用開発含む)とそれを評価するツールとなること、これが弊社Cortex-M4テンプレートの目標です。

評価の結果、仮にMCUやIoTセンサ、無線機能の再選択が必要となっても、開発部分の多くが次に即座に流用できるソフトウェア資産となるには、汎用STM32G4によるIoTプロトタイプ開発が有効だと思います。

具体的には、従来テンプレートとは「対象者レベルと目的を変える」ことを検討中です。

  • 従来Cortex-M0/M0+/M3テンプレートは、対象者が初心者/中級レベル開発者で、MCU基本動作(Simpleテンプレート)とADC/LCD動作(IoT汎用Baseboardテンプレート)を提供し、基本的なMCU理解と開発が目的のテンプレート
  • Cortex-M4テンプレートは、対象者が中級レベル以上の開発者で、MCU基本動作などは省き、IoTプロトタイプ開発高速化が目的のテンプレート

本稿説明がすんなりとご理解頂ければ、中級レベル以上の開発者、Cortex-M4テンプレート対象者だと思います。

Cortex-M4テンプレートの対象レベルと目的
Cortex-M4テンプレートの対象レベルと目的

News

2021年1月12日、STM32CubeとMicrosoftのAzure RTOSが統合、STM32マイコン開発環境で協力というニュースが発表されました。STのCortex-M4テンプレートは、FreeRTOSとAzure RTOSの両方が必要かもしれません。

STブログに、上記の詳細情報があります。

2020マイコンテンプレート案件総括

COVID-19パンデミックの2020年も残すところ2週間になりました。2020年の金曜ブログ投稿は本日が最後、次回は2021年1月8日(金)とし休暇に入ります。

※既存マイコンテンプレートは、年中無休、24時間販売中です、いつでもご購入お持ちしております。

2020マイコンテンプレート案件総括

  1. 🔴:Cortex-M4コア利用のマイコンテンプレート開発(2020年内)
  2. 🟡:FRDM-KL25ZとIoT汎用Baseboard利用のKinetis Lテンプレート発売(12月)
  3. 🟢:IoT MCU向け汎用Baseboard開発(10月)
  4. 🟢:STM32FxテンプレートV2発売(5月)
  5. 🟢:STM32G0xテンプレートV2発売(5月)

1のCortex-M4テンプレート開発は、STM32G4のRoot of Trustと、NXP LPCXpresso54114のRTOSサンプル解説で、Cortex-M4テンプレート化には程遠い状況です(赤ステータス)。

2のKinetis Lテンプレート(FRDM-KL25Z、Cortex-M0+/48MHz、Flash:128KB、RAM:16KB)は、添付説明資料作成が未着手です(黄ステータス)。

3のArduinoプロトタイプシールド追加、IoT MCU汎用Baseboardは完成しました(緑ステータス)。

4と5のSTM32FxテンプレートSTM32G0xテンプレート発売までは、ほぼ順調に進みました(緑ステータス)。

対策としてブログ休暇中に、2のKinetis Lテンプレート完成と、これに伴うHappyTechサイト変更を目標にします。
1のCortex-M4テンプレート開発は、2021年内へ持越します。

ブログ記事高度検索機能(1月8日までの期間限定)

休暇中、ブログ更新はありません。そこで、読者の気になった過去の記事検索が、より高度にできる下記Googleカスタム検索機能を、1月8日までの期間限定で追加します。

上記検索は、WordPressのオリジナル検索(右上のSearch…窓)よりも、記事キーワード検索が高度にできます。少しでもキーワードが閃きましたら、入力してご活用ください。

あとがき

激変の2020年、テンプレート関連以外にも予定どおりに進まなかった案件や、新に発生した問題・課題も多数あります。例年より少し長めの休暇中、これらにも対処したいと考えております。今年のような環境変化に対し、柔軟に対応できる心身へ変えたいです(ヨガが良いかも? 3日坊主確実ですが…😅)。

本年も、弊社ブログ、HappyTechサイトをご覧いただき、ありがとうございました。
今後も、引き続きよろしくお願いいたします。よいお年をお迎えください。

Cortex-M33とCortex-M0+/M4の差分

STマイクロエレクトロニクスが、STM32マイコン体験実習(セキュリティ編①~⑤)という動画でCortex-M33 TrustZone解説とSTM32L5(Cortex-M33/110MHz、Flash/256/512KB、RAM/256KB)のセキュリティ実習を行っています。

このセキュリティ編①:31min17secから、IoT MCU向けセキュリティ強化Cortex-M33コアのARM TrustZoneマイコンと、通常Cortex-M0+/M4コアマイコンとの差分を抽出しました。TrustZoneマイコン基礎知識の習得が目的です。

Cortex-M33とCortex-M0+/M4差分

セキュリティ編動画①~⑤概要

①P3(動画①、スライドP3を示します)に、動画①~⑤の概要が示されています。動画①でCortex-M33コアの解説、②でSTM32L5開発環境の準備、後半③~⑤でSTM32L5評価ボード:NUCLEO-L552ZE-Q(¥2,303 Mouser)を使ったセキュリティ演習という構成です。

本稿は、動画①から、ARM TrustZone Cortex-M33コアと通常Cortex-M0+/M4コアとの差分を一覧表にしました。

※ARM公式差分情報を知りたい方は、①P48の参考文献が参考になります。

Cortex-M33とCortex-M0+/M4の差分

オンデマンド動画ですので、好きな個所で止める、再生読度を変えるなどが可能です。動画①は、筆者が経験したTrustZone解説の中で最も分かり易い動画です。

特にP36/P37/P39は、4段階に増えたステート処理内容が具体的に判りTrustZoneマイコン特徴理解に役立ちます。
また、P19は、様々なセキュリティレベルと対応STM32MCUのセキュリティ機能差が一目で判る重要な資料です。

要旨(ARM TrustZone Cortex-M33と通常Cortex-M0+/M4差分)
7 ソフトウェア攻撃防御策がTrustZone。物理攻撃対策はセキュアマイコン(≠汎用MCU)が有効。
12 Secure呼出し=予め決めた手順で内蔵周辺回路(I2C/SPI/RAMなど)へアクセスする技術
Security Isolation=Secure呼出しを使い通常アクセスと隔離・分離する技術
ARM TrustZone=Security Isolationを対象MCUで柔軟に構成する技術
16 タンパ=物理攻撃を検出→検出後バックアップレジスタやSRAM自動消去
JTAGピン無効化→設定後はGPIOなどで運用
WRP(WRite Protection):数KB単位設定可能
RDP(ReaD Protection):JTAG読出し禁止→読出検出でプログラム実行停止→PORで解除
Secure Memory=起動時のみ読出し可能な領域
17 MPU(Memory Protection Unit):最大16個メモリ領域の読書き、命令実行許可/禁止設定
18 セキュリティは単独では効果が薄く、複数重ね攻撃への敷居を上げ強化(暗号鍵保存例掲載)
19 STM32マイコン内蔵セキュリティ機能差一覧。TrustZone対応はSTM32L5のみ(2020/12時点)
STM32G0/G4(Cortex-M0+/M4)でもSRAM RDP機能などあり
22 TrustZoneは、アドレス空間とバス通信の両方をハードウェア監視しアクセス制御
23 アドレス空間監視=コア内蔵SAU IDAU、バス通信監視=TZ(TrustZone) ControllerとAHBバス
24 STM32L5は、内部FlashアクセスにST独自Flashレジスタとオプションバイトで保護
26 TrustZone-aware周辺回路=DMA1&2/GPIO…などAHB接続回路は個別セキュリティ設定要
上記以外がSecurable周辺回路=UART/SPI…などでAHB/APBブリッジがアクセス監視
29 従来MCUベアメタル開発は、mainループも割込みハンドラも常に特権モード動作の1段階
30 従来MCUのRTOS開発は、割込みハンドラ/RTOSが特権モード、ユーザタスクは非特権の2段階
32 Secureステート追加TrustZoneは、4段階化→各層の処理配置がTrustZoneソフト設計第一歩
35 Secureソフトと従来ソフトのプロジェクト差一覧
(セキュリティ関連設定はSecureソフトのみ可能でmain関数はあるがmainループなしなど)
36 TrustZoneマイコンベアメタル開発の4段階ステート処理配置例(TrustZoneソフト設計例1)
37 TrustZoneマイコンRTOS開発の4段階ステート処理配置例(TrustZoneソフト設計例2)
38 TrustZoneソフト開発時、Secureソフトと通常ソフトの2プロジェクト作成必要
39 TrustZoneソフトの基本実行フロー(Secureソフトから通常ソフトへの処理内容一覧)
40
41
42
Secureステートと通常ステートのアドレス空間の見え方差まとめ
44 動画①全体まとめ
45 STM32L5開発時のキーポイント一覧(全18項目)
46 STM32L5開発時のキーポイント演習項目一覧(18項目中9項目を動画③~⑤で演習)
48 おすすめARMv8-M(Cortex-M33コア)TrustZone参考文献一覧

TrustZoneマイコン開発は工数2倍、スキルも必要

動画①は、他ベンダのARM Cortex-M33 TrustZoneマイコン開発でも基礎知識が得られます(※P24のST独自Flashレジスタとオプションバイト保護は除く)。IoT MCU向けセキュリティ強化Cortex-M33コアで導入されたTrustZoneを活用するには、①の理解は最低限必要です。

従来Cortex-M0+/M4に比べ、Cortex-M33シングルコア開発でもSecureと通常(Normal)ソフトウェアの2プロジェクト必要、メモリ空間と周辺回路のセキュリティ設定必要(メモリ分割損も生じると予想)、JTAGピン無効化など、従来のアプリケーション開発とそのデバッグに加え、ソフトウェア攻撃対策TrustZone導入による工数やその動作確認/解除などの手間が余分に必要になります。

このTrustZone導入オーバーヘッドは、少なくないです(セキュリティ編②~⑤でオーバーヘッド工数が判ります。補足章に動画②~⑤リンク添付)。Cortex-M33コア最高速度が110MHzと他コア比高速で、Flash/RAMも大容量なのは、このオーバーヘッドのハードウェア対策だと思います。

TrustZoneマイコンのソフトウェア開発工数は、同じアプリケーションの通常マイコン開発の2倍程度は必要になると思います。また、TrustZone起因のトラブルに対する分析スキルも必須です。

ソフトウェア攻撃に対する防御壁の高さは、言い換えると、ソフトウェア開発のし難さと等価です。セキュリティレベルが上がるにつれ、開発コストも上がります。

全てのIoT MCUがTrustZone対応MCUである必要は無いと思います。コスト重視の場合は、従来Cortex-M0+/M4コアでセキュリティ強化対応(例えば、関連投稿:STM32G0/G4のRoot of Trust(1)~(3)など)でも使える可能性があります(関連投稿:IoT MCUコア次世代像のIoT MCUコアの3層構造最下層のFront End IoT MCUに相当)。

セキュリティは、強固な方が良いのは当然ですが、それ相応の追加コストも生じます。セキュリティ対コストの観点からIoT MCUの選択が必要となるでしょう。

* * *

セキュリティ対策は、いわば自動車保険のようなものです。保険代金の負担は、開発者かエンドユーザか、エンドユーザがTrustZone導入オーバーヘッドを理解することは難しいと思いますので悩ましい問題です😅。

Cortex-M33 TrustZoneマイコンは、ソフトウェア開発者が記述した処理を攻撃とマイコンが誤認識(正常認識)した場合は、無視、あるいは最悪、マイコンを使用不能にします。見つけにくい無視された処理が、開発者起因か、あるいはTrustZone起因かを分析できるスキル、これが、通常マイコン開発との最大の差分です。

STM32マイコン体験実習は、TrustZone起因スキルを習得できるよく考えられた教材です。

補足

STM32マイコン体験実習(セキュリティ編②
STM32マイコン体験実習(セキュリティ編③
STM32マイコン体験実習(セキュリティ編④
STM32マイコン体験実習(セキュリティ編⑤

関連投稿:STM HTML版マンスリー・アップデートの見かた4章の全体像リンク集なども役立ちます。

Cortex-M33コア以外でTrustZone技術を用いたマイコンは、Cortex-M35P、Cortex-M23があります。

IoT MCUの無線LAN

IoTに適した無線LANの条件とは?(TechTarget、2020年11月27日)記事を紹介し、IoT MCU関連のプライベート網無線LAN規格を説明します。

IoT向き無線LAN条件と規格

纏まった良い記事なので、一読をお勧めします。

記事を要約すると、IoT向きの無線LANの選定には、3つの検討ポイントがあります。

  1. 省電力性:バッテリーだけで長時間無線LAN通信ができる
  2. 長距離伝送性:アクセスポイント(AP)から1km以上離れる場合がある
  3. 国より異なる利用周波数の空き状態確認

各ポイントを満たす無線LAN規格として下記3つを挙げ特徴を説明しています。

  • IEEE 802.11ah(別名Wi-Fi HaLow):Target Wake Time(TWT)により通信タイミングを調整しAP通信競合を防ぐと同時にスケジュールタイムまでスリープし電力消費を抑える
  • IEEE 802.11ba:TWTに加えWake-Up Radio省電力機能を利用しAPからの通信要求に対応
  • IEEE 802.11af: 54MHz~698MHz利用で900MHz~1GHzの802.11ah/802.11baより長距離伝送可能
    ※11afは、テレビ用ホワイトスペースのVHF/UHFバンド(54 MHz~790 MHz)利用なので空き状態により耐ノイズ注意

IoT向き無線LANとBluetooth

無線LANには、2.4GHz利用、数m~10m程度の「近距離無線通信規格」:IEEE 802.15.1(別名Bluetooth)もあります。コイン電池で1年以上動作できるなど超省電力動作ですが、低速です。PCやスマートフォンでは、マウス/キーボード/ヘッドホンなどの周辺機器との接続に使われます。

より高速、より長距離(400m程度)、より高スループットを目指し、Bluetooth v4.2、Bluetooth 5などと規格が変化しています。

IoT MCUへの実装は、Bluetooth 5内蔵MCUBluetooth 5モジュールとMCUを接続する方法があります。

IoT 向き無線LANとPC/スマホ向き無線LAN

2020年12月時点のPC/スマートフォン無線LAN規格が下表です(出展:NTT西日本公式ホームページ)。

規格 周波数帯 最大通信速度
IEEE 802.11b 2.4GHz 11Mbps
IEEE 802.11g 2.4GHz 54Mbps
­­­­IEEE 802.11a 5GHz 54Mbps
IEEE 802.11n 2.4GHz 600Mbps
5GHz
IEEE 802.11ac 5GHz 6.9Gbps
IEEE 802.11ad(WiGig) 60GHz 6.8Gbps
IEEE 802.11ax 2.4GHz 9.6Gbps
5GHz

IoT向き無線LANと異なるのは、周波数帯がより高周波の2.4GHz/5GHzを利用する点と、新規格11ac/11ad/11ax、従来規格11b/11g/11a/11n、ともにデータ伝送速度が速い点です。スマホのAPは、家庭や店舗に設置された無線LANルータで、高周波利用のため伝送距離は精々100m程度、60GHzの11adでは10m程度です。公衆網5G高速化に伴い新無線LAN規格:11ac/11ad/11axが普及しつつあります。

動画再生などの利用形態も多いPC/スマホ向き無線LANは、「高速大容量化」が求められます。IoTの「長距離省電力」要求とは、異なる無線LAN規格となっています。

まとめ:IoT MCUプライベート網の無線LAN規格

無線LANアクセスポイントからの伝送距離変化
無線LANアクセスポイントからの伝送距離変化

プライベート網無線LAN規格は、APからの伝送距離により、

  1. 「近距離(10m以下)超省電力」規格(周辺機器向き):Bluetooth(IEEE 802.15.1)
  2. 「短距離(100m程度)高速大容量」規格(PC/スマホ向き):IEEE 802.11a/11b/11g/11n/11ac/WiGig(11ad)/11ax
  3. 「長距離(1km以上)省電力」規格(IoT向き):Wi-Fi HaLow (IEEE 802.11ah)/11.af/11.ba

の3種類があります。

IoT MCUには、最新のBluetooth 5や屋外や1km半径の広い敷地内でも使える長距離省電力規格のWi-Fi HaLowが望まれるようです。

但し、普及済みのPC/スマホ向き無線LAN規格が使えると、屋内の既存PC/スマホ無線LANルータをインターネット空間へのAPに利用でき、常時電力供給も可能なため、低コストIoT MCUを実現する方法になりうると思います。


IoT MCUコア次世代像

PCのCPUは、IntelとAMDの2社が独占状態でした。しかし、AppleがARMベースの新CPU:M1を発表し、そのコストパフォーマンスは、Intel/AMDの3倍(!)とも言われます(記事:「ソフト技術者もうなるApple「M1」の実力、新アプリに道」や、「Apple M1の実力を新世代のIntel/AMD CPUと比較」など)。

本稿は、これらPC CPUコアの現状から、次世代IoT MCUコアの3層構造と筆者希望的観測を示します。

CPUコア:Apple/Intel/AMD

筆者が学生だった頃は、マシン語のPCソフトウェアもありました。CPUコア性能が低いため、ユーザ要求を満たすアプリケーション開発には、ソフトウェア流用性や開発性を無視したマシン語開発もやむを得ない状況でした。

現在のCPUコア性能は、重たいGUIやネットワーク処理を複数こなしても、ユーザ要求を満たし、かつ流用性も高いC/C++などの高級言語でのアプリケーション開発が普通です。Appleは、この状況でIntel/AMDコストパフォーマンス比3倍のM1 CPUを開発しました。

このM1 CPUを使えば、従来CPUのボトルネックが解消できるために、より優れたGUIや新しいアプリケーションの開発が期待できます。

このM1実現の鍵は、5nmルールの製造技術と新しいCPU設計にあるようです。

MCUコア:ARM/Non ARM

MCUはARMコアとNon ARMコアがありますが、Non ARMコアのコストパフォーマンス比は、M1程ではありません。従って、主流はARM Cortex-M系シングルコア採用MCUで、事実上ARMコア独占状態です。開発言語はC言語でベアメタル開発、製造プロセスも数10nmと、いわば、数10年前のIntel独占CPUコアに近い状況です。

RISC-Vという新しいMCUコアも出てきましたが、まだ少数派でその性能も未知数です。Intel/AMD CPUと比較記事の最後に記載された「競争こそユーザの利益」には、MCU世界はなっていません。

ARMはコア設計図のみ提供し、デバイス実装はMCUベンダが担当します。従って、現状のMCU世界が続く場合には、MCU高速化は製造技術進化とマルチコア化が鍵です。

ARMは、エッジAIに向けたNPUを発表しました。独自MCUコアと付随する開発環境を提供でき、かつコストパフォーマンスがARMコアの数倍を実現できるMCUベンダが無い現状では、ARMの頑張りがIoT MCUを牽引すると思います。

NVIDIAによるARM買収が、今後のARM動向に及ぼす影響は気になる状況ではあります。

IoT MCUコア

MCUコアとCPUコアの一番の差は、ユーザ要求コストです。これは、同じコアのMCU製品に、内蔵周辺回路やFlash/RAM容量の異なる多くのデバイスをベンダが提供中であることからも解ります。ユーザは、MCUに対して無駄なコストは払いたくないのです。

つまり、MCUデバイスはアプリケーション専用製品、CPUデバイスは超汎用製品、ここが分岐点です。

IoT MCUには、エッジAI、セキュリティ、無線通信(5GやWi-Fi)などのIoT機能追加が必要です。これら機能を並列動作させる手段として、RTOSも期待されています。この状況対応に、MCUコアも高性能化やマルチコア化に進化しつつあります。

セキュリティや無線通信は、予め決まった仕様があり、これら対応の専用ライブラリがベンダより提供されます。但し、セキュリティは、コストに見合った様々なセキュリティレベルがあるのも特徴です。ソフトウェア技術者は、専用ライブラリのMCU実装には神経を使いますが、ライブラリ本体の変更などは求められません。この仕様が決まった部分を「IoT基本機能」と本稿では呼びます。

MCUソフトウェア開発者が注力すべきは、ユーザ要求に応じて開発するIoTアプリケーション部分です。この部分を、「IoT付加機能」と呼び、「IoT基本機能」と分けて考えます。

ユーザのアプリケーション専用MCU製品意識は、IoT MCUでも変わりません。例えば、IoT基本機能の無線機能は不要や、ユーザがコストに応じて取捨選択できるセキュリティレベルなどのIoT MCU製品構成になると思います。一方、IoT付加機能だけを実装するなら、現状のMCUでも実現可能です。

以上のことから、IoT MCUは3層構造になると思います。

IoT MCUコアの3層構造
IoT MCUコアの3層構造

機能 追記
Back End IoT MCU IoT基本機能+付加機能+分析結果表示 収集データ分析結果ビジュアル表示
IoT MCU IoT基本機能+付加機能 高性能、マルチコア、RTOS利用
Front End IoT MCU センサデータ収集などのIoT付加機能
最小限セキュリティ対策
収集データは上層へ有線送信
コスト最重視

最下層は、ユーザ要求アプリケーションを実装し、主にセンサからのデータを収集するFront End IoT MCUです。ここは、現状のARM/Non ARMコアMCUでも実現できIoT付加機能を実装する層です。デバイスコスト最重視なので、最小限のセキュリティ対策と収集データを有線、または無線モジュールなど経由で上位IoT MCUへ送信します。IoT MCUサブセット版になる可能性もあります。

中間層は、高度なセキュリティと市場に応じた無線通信、エッジAI機能などのIoT基本機能がフル実装できる高性能MCUコアやマルチコア、RTOS利用へ進化した層です。IoT付加機能も同時実装可能で、下層の複数Front End IoT MCUが収集したセンサデータを、まとめて上位Back End IoT MCUまたは、インターネット空間へ直接送信できます。製造技術進化とマルチコア化、ARM新コア(Cortex-M23/33/55など)が寄与し、IoT MCUの中心デバイスです。

最上層は、第2層のIoT MCU機能に加え、インターネット空間で収集データを分析・活用した結果をユーザへビジュアル表示する機能を追加した超高性能MCUコア活用層です。自動車のADAS(Advanced Driver-Assistance Systems:先進運転支援システム)のおかげでユーザへのビジュアル表示要求はより高度になります。このユーザ要求を満たす次世代の超高性能IoT MCU(またはMPU)が実現します。

最下層のFront End IoT MCUは、現状のCortex-M0+/M4コアで弊社テンプレート適用のMCUが生き残ってほしい、というのが筆者の希望的観測です。
それにしてもAppleのコスパ3倍M1、凄いです。iPhoneもそうですが、抜きん出た技術と経営能力、Jobs精神、健在ですね。

総務省IoT入門オンライン講座

総務省総務省が、2021年3月24日まで無料IoT入門オンライン講座を開設しています。IoT基礎知識、IoT技術・関連法制度、IoT活用の全3章から成るPDF配布資料(A4/36ページ)付きで各ページ冒頭に2行程度のまとめ表記があります。

※受講方法は、コチラの記事を参照してください。

資料作成日:令和元年10月

COVID-19パンデミック前、令和元年:2019年10月作成資料に沿ったオンライン講座です。関連法の導入時期などに、COVID-19の影響があるかもしれません。

※関連投稿:総務省2020年4月以降IoT機器アップデート機能義務化予定(2019年9月13日)に関する記載は、資料内にはありません。

資料フォーマット

A4縦ページの上方にスライド、下方にテキスト、いわゆるパワーポイントノート形式の配布資料です。タイトル直下、スライド冒頭に2行程度のまとめ表記があり、このまとめでページ内容が解ります。

オンライン講座は、主にスライド部分を使います。配布資料を読めば、講座内容はほぼ取得できると思います。

IoT入門オンライン講座資料の印象点

A4パワーポイントノート形式のIoTオンライン講座配布資料、良くまとまっています。

資料のWeb転載は禁止ですので、本ブログ読者は配布資料を取得済みと考え、筆者がページ毎に印象に残った点をピックアップします。

※タイトル、まとめ表記は、配布資料を基に簡素化しています。

タイトル まとめ表記 印象点
13 IoT構成機器 IoTシステム構成は3要素 データ収集、分析結果表示がIoTデバイス
14 データ収集 センサでデータ収集 8種センサ概要説明
15 IoTデバイス通信 有線と無線の2種 有線/無線のメリット/デメリット分析
17 無線電波周波数 最適な周波数 波長/周波数/呼び名/特徴分析
18 電波法 電波利用法 無線利用時「技適マーク」必須
19 無線通信 距離・速度・消費電力 無線規格特徴一覧、選択に便利
23 セキュリティ 機密性・完全性・可用性 機密性と完全性と可用性維持がセキュリティ
24 セキュリティ対策 リスクと対策 IoT特有性質とリスク分析
25 セキュリティ対策 対策の5指針 5指針と21要点、具体例一覧
26 標準化動向 標準技術メリット 4標準化団体と最新技術動向把握重要
28 IoT進め方 アイデア → 試行錯誤 プロトタイプで試行錯誤 → 導入
29 ビジネス設定 IoT解決課題設定方法 情報整理に3C/SWOT/KPT活用
30 アイデア案出 IoT活用の3段階 アイデア案出方法
31 アイデア優先順位 効果と実現可能性 効果、実現可能性の考慮方法
32 データ留意点 利害関係調整と個人情報保護 具体的留意点説明
33 運用後の対応 想定と対応策 想定具体的トラブル説明

P28のIoTデバイスをプロトタイプで試行錯誤し開発する手法は、弊社マイコンテンプレートを利用すると、「複数デバイスで実証・比較評価できるなどより効率的・実践的」になります。

マイコンテンプレートのMCUデバイスはどれも汎用MCUですが、開発者のナレや接続センサとADCの使い方により差は生じます。さらに、デバイス消費電力も、開発ツールシミュレーションと評価ボードで評価します。最もアイデアに適し開発し易いMCUは、実はプロトタイプ化しなければ判らないと思います。

配布資料は、「IoTデバイスを中心」に基礎から導入後の運用など、IoT全般に関する幅広い内容です。IoTデバイス開発者の頭の中を整理、開発後のデバイス活用・運用などを予見する場合にも役立ちます。

資料にもCOVID-19影響?

スライド利用のプレゼンテーションは、パワーポイント/Impress(LibreOfficeパワーポイント相当)の資料作成が標準です。一方、弊社テンプレート配布資料は、A3 Visio/Draw形式で作成しています。これは、横長PCモニタ表示を前提としているからです(印刷時、70%縮小A4横出力想定)。

COVID-19の影響で、プレゼンテーションも対面からオンラインへ変わりつつあります。配布資料も従来のようにパワーポイント/ Impress形式が良いか、Visio/Draw形式か、モニタも3:4サイズが良いか、9:16かなど、配布資料フォーマットにも今後影響がでるかもしれません。

弊社テンプレート開発、配布資料のご意見、ご要望などは、info@happytech.jpへお寄せください。

IoT MCU汎用Baseboardの汎用性

・IoT MCU汎用Baseboardの特徴
・CMOSデバイス直結を利用し、3.3V動作MCUソフトウェア開発に5V動作ハードウェアを使えること

をFRDM-KL25Z(動作範囲:1.71~3.6V、5V耐圧なし)を例に前稿で示しました。
このIoT MCU汎用Baseboard の汎用性について解りにくいというご指摘がありましたので、説明を加えます。

IoT MCU汎用Baseboard構成パーツ

IoT MCU汎用Baseboardの構成パーツが下図です。

Arduinoコネクタ有りのMCU評価ボードはFRDM-KL25Zを掲載しましたが、Arduinoコネクタを持たない例えば、Cypress)PSoC4000SなどのMCU評価ボードでも接続可能です。これが汎用性をうたった理由です。

様々な追加Arduinoシールドは、Arduinoコネクタでスタック接続、それ以外のパーツ間は、オス-オスコネクタで接続します。

IoT MCU汎用Baseboard構成(色付き領域)
IoT MCU汎用Baseboard構成(色付き領域)

一言で言うと、従来から使ってきた5V Baseboardに、Arduinoプロトタイプシールドを追加した構成です。

IoT MCU汎用Baseboard構成パーツの役割

パーツ名 機能、役割
MCU評価ボード 動作電圧:3.3V/5V動作のMCUソフトウェア開発ボード
外部ハードウェア接続:Arduinoコネクタ/独自コネクタ
追加Arduinoシールド IoT向けセンサなどをMCU評価ボードへ機能付加
Arduinoプロトタイプシールド シールド直上へスタック接続(Arduinoピン名シルクあり)
配線済みMCUリセット、未配線2個LED、1個SW実装済み
MCU評価ボード直上設置で操作性向上
5V Baseboard LCDやポテンショメータなど5V動作ハードウェア搭載
オス-オスコネクタ ボード、各パーツ間接続
Arduinoコネクタ Arduinoシールドスタック接続
CMOSデバイス直結 3.3V MCU出力→5Vハードウェア入力:接続問題なし
5Vハードウェア出力→3.3V MCU入力:5V耐圧無しなら3.3V以下
付属ブレッドボード CMOSデバイス直結時、電流保護抵抗や必須ハードウェア搭載

MCUに5V耐圧が無い時は、MCU入力電流保護抵抗や入力電圧を3.3V以下へ抑える必要があり、これら必須ハードウェア、およびArduinoプロトタイプシールド付属の2個LED、1個SW配線用に、プロトタイプシールド付属ブレッドボードを使います。

IoT MCUは、MCU評価ボード搭載済み機能だけでなく、様々なセンサや付加機能(例えば、構成パーツで示したデータロギングシールドなど)を追加して開発します。これら追加センサや付加機能ハードウェアを、安く早く調達するには、既製Arduinoシールドが適しています。

殆どのMCU評価ボードがArduinoシールドを追加できるように設計されているのはこのためです。Arduinoプロトタイプシールドは、Arduinoピン名がシルク印刷済みです。Arduinoピン名とMCUピン名のマッピングを間違う可能性も低く、リセット追加で制御系の操作性も向上します。

Arduinoコネクタ実装済みのFRDM-KL25Zの場合は、直上、または直下へArduinoシールドをスタック追加します。FRDM-KL25Z追加シールド処理結果を表示するため、プロトタイプシールド経由で5V Baseboard LCDと接続します。

独自コネクタで機能追加するPSoC4000S評価ボードなどに対しても、オス-オスコネクタでArduinoプロトタイプシールドと接続すれば、それ以外の部分は共通です。この時は、プロトタイプシールド直下にArduinoシールドを追加します。

※Arduinoシールドを複数追加する時は、スタック接続します。

様々なMCU評価ボードに対して、表中のMCU評価ボード以外の赤字パーツが汎用的に使え、かつ、Arduinoシールド追加性にも優れていることがお解り頂けたと思います。

IoT MCU汎用Baseboard用途

CMOSデバイス直結は、ハードウェア担当者からは、気持ちが悪いと言われるかもしれません。

この場合は、CMOSデバイス間にバス・スイッチ(SN74CB3T3245)を挿入すれば、パッシブデバイスですので高速性や信頼性、ノイズに対しても安心です。もちろん、動作ソフトウェアは同じものです。詳細は、関連投稿:3.3V MCUと5Vデバイスインタフェースを参照してください。

このIoT MCU汎用Baseboardは、早く、安くIoT MCUソフトウェア開発をするためのソフトウェア担当者向けツールという位置づけです。製品化にあたっては、ハードウェア担当者も安心するようにバス・スイッチの利用をお勧めします。

5G、Wi-Fi6、NXP、STマイクロエレクトロニクス

公衆網の5G、無線LANのWi-Fi6、どちらもIoT MCUに必須となる無線通信技術です。本稿は、5GとWi-Fi6、MCU主要ベンダのNXPとSTマイクロエレクトロニクス2社の無線対応状況を簡単にまとめます。

5GとWi-Fi6

5GやWi-Fi6、Bluetoothは、無線通信技術です。違いは、5GがNTTやau、SBが提供する公衆網サービス、Wi-Fi6やBluetoothは、LANを無線化したプライベート網サービスだということです。

これら公衆網とプライベート網、両方の無線技術やサービスを積極的に活用するデバイスが、毎年新製品が発表されるスマートフォンです。搭載カメラやスマホ操作性だけでなく、5GやWi-Fi6実現のためにスマホプロセッサの性能向上は必須です。

5GやWi-Fi6の市場は急増中です。これら市場に対応するため、スマホは常に最新無線技術、高性能プロセサへと変わらなければならない運命です。開発担当者は大変でしょう。

5G、Wi-Fi6技術牽引はスマホと自動車

自動車業界のADAS:Advanced Driver-Assistance Systems、先進運転支援システムの開発速度もスマホ同様高速です。数年でモデルチェンジする新車に搭載する様々な新しい支援機能が、売上げを左右するからです。

これら新搭載機能にバグはつきものです。例えば、制限速度標識の車載カメラ認識はかなりの精度ですが、一般道で認識速度が110 km/hと表示された経験があります。メータ表示だけなので、車速が自動で上がることはありませんが…、バグです。

一般道で110km/h表示:フェールセーフでなくバグ
一般道で110km/h表示:フェールセーフでなくバグ

このようなバグに対して、2022年7月以降の新車は、スマホのようにOTA:Over-The-Airで車載ソフトウェアのアップデートを行う国際基準が発表されました。サイバーセキュリティ対策や走行安全性にも絡むので、かなりの処理が開発担当者に要求されると思います。

ついに自動車もスマホ同様、ソフトウェアOTA必須になります。インダストリアル業界も、当然ながら自動車業界OTAと同様の仕組みとなるでしょう。

無線技術やセキュリティ、AIなどの先端技術は、一般消費者の旺盛な購買力の対象となるスマホと自動車が牽引することは間違いありません。競争が激しく開発成果も解り易いのですが、開発者担当は最新技術習得の余裕も少なく、実装期限が限られるためセルフマネジメントが大変です。

NXP対応

NXPは、2020年9月に5G無線システム向け製造工場の稼働開始を発表し、2021年初頭までにフル稼働、5Gや次の6G向け無線チップを自社製造できる見通しです。また、NXP本社副社長でもあるNXPジャパン新社長の和島正幸氏の就任も発表されました。

せっかく開発した量産電気自動車(Electric Vehicle)の販売予約中止の原因は、車載バッテリーの供給が追付かないからだそうです。無線システムのかなめ、RFチップ供給が同じ状況になるのを避けるためのNXPの措置だと思います。

STマイクロエレクトロニクス対応

STマイクロエレクトロニクスは、2020年10月7日、無線LANのBluetooth LE 5.2対応Cortex-M0+ベースMCUとその評価ボードを発表しました。Arduinoコネクタ付属で、使い勝手も良さそうな気がします。

STEVAL-IDB011V1 Evaluation Board and Updated BlueNRG Software(出展:STマイクロ)
STEVAL-IDB011V1 Evaluation Board and Updated BlueNRG Software(出展:STマイクロ)

IoT MCUの爆発的な需要増加に対して、MCU主要ベンダのNXPやSTマイクロエレクトロニクスは、着々と準備を進めています。

インダストリアル業界IoT端境期

スマホや自動車業界のように競合他社より少しでも早く最新技術を導入し製品化する動きに対し、インダストリアル業界は、COVID-19の影響でIoT技術導入の端境期のようです。つまり、積極的にIoTを進めるデンソーのようなグループと、暫く様子見をして徐々にIoTを進めるグループの2つに分離しつつあるということです。

インダストリアル業界対応の開発者は、この端境期を逆に利用し、IoT最新技術を学習しつつ、来るべきIoT開発案件をこなす力を備えるチャンスです。

具体的には、自動車やスマホで先行した無線/セキュリティ/AI技術を、効率的にIoT MCUへ流用・応用できる開発力です。または、MCUベンダ提供の無線/セキュリティ/AI最新技術サンプルプロジェクトを理解し、評価ボードを上手く活用できる開発力とも言えます。

インダストリアル業界の顧客出力となるソフトウェア/ハードウェアを、要求期限内に開発成果として提出できるベストエフォート技術、この比重が増すと思います。開発成果の不完全さやセキュリティ追加、変更はOTAで対応します。

Firefox Send終了

クラウドファイル共有サービス:Firefox Sendが2020年9月17日終了となりました。弊社テンプレート配布に最適なFirefox Send終了、残念です。代替にGoogle Driveを使いますが、送受双方に手間が1つ増えます。

本稿は、この増えた手間を説明し、セキュリティと利便性が相反することを示します。

Firefox SendからGoogle Driveへクラウドファイル共有サービス変更
Firefox SendからGoogle Driveへクラウドファイル共有サービス変更

Firefox SendとGoogle Drive比較

Firefox Sendは「ファイル共有」専門サービス。共有ファイル保存期間はアップロード後最大7日、または、ダウンロード1回で共有ファイルがオンライン上から自動的に消去されるなど、「ファイル保存」が主目的のGoogle Driveにない使い勝手がありました。

ファイル共有Firefox Sendとファイル保存Google Drive比較
Firefox Send Google Drive
ファイル共有期間 最大7日 設定不可
受信側ダウンロード回数 1回 設定不可
利用料金 無料(最大2.5GB) 無料(最大15GB)
ダウンロード側ログイン 不要 不要
パスワード保護 可能 可能
特徴 ファイル共有に最適 ファイル保存に最適

共有ファイルダウンロードリンクを送信側から受信側へメール通知、受信側がFirefox/Chrome/Edgeなどのモダンブラウザを使って共有ファイルダウンロードに成功しさえすれば、ファイル共有は終了です。ここまでは、Firefox SendとGoogle Drive全く同じです。Firefox Sendは処理完了です。

違いは、Google Driveがファイルの共有期間やダウンロード回数の制限を設けることができない点です。また、受信側が共有ファイルをダウンロードしたことを、送信側が知る手段もありません。

Google Driveでのダウンロード成功後、受信側に成功通知メールをお願いするのは、Firefox Sendでは自動で行われる共有ファイル削除、または、共有停止を送信側が手動にて行うためです。

Firefox Sendに比べ、Google Driveでは送受双方に処理完了までにこの手間が1つ余分に掛かる訳です。

Firefox Send終了理由

Firefox Sendサービス終了の理由は、マルウェア配布手段として悪用されるケースが増え、開発元Mozillaがサービスラインナップ全体コスト、戦略的焦点を見直した結果と発表されています。

高度な暗号化とファイル自動消去のFirefox Send共有サービスは、Firefoxという誰にでも知られた信頼性の高いダウンロードリンククリックだけで簡単にマルウェアをデバイスへ送れます。一般のユーザだけでなく、ハッカーにとっても便利なツールとして悪用されたのでしょう。

無料一時保存ファイルのマルウェア排除を実施することは、無理だとMozillaがあきらめたのだと思います。ただ、次々に生まれるマルウェア排除は、たとえ有料でも困難かもしれませんが…。

セキュリティと利便性の相反例です。また、セキュリティとその対価:費用対効果を考えさせる例でもあります。

企業が自社クローズドサーバーでのみ社員ファイル共有を許可するのは、費用対効果の実現解なのでしょう。
※同様に、IoT MCU開発でもセキュリティ実現解検討が必須です。

Google Drive代替理由

Firefox Send代替にGoogle Driveを選んだ理由は、ファイルの「ダウンロード前や共有前」に、ウィルススキャンが自動的に行われるからです。ウィルス検出時は、警告表示があります。

※ウィルススキャンは圧縮ファイルでも実施されます。但し、パスワード保護を行うとスキャン不可能になりますのでパスワードは設定しません。Firefox Sendでもこれら処理は実施されていたと思いますが…、ハッカーはパスワード保護でスキャンをかわしたのだと思います😥。

無償、セキュリティ、信頼度の高さ、モダンブラウザで利用できる点、これらからGoogle Driveを代替として弊社は選びました。

全テンプレート継続販売

販売中の弊社テンプレートは、戦略的焦点(???)から販売継続いたします。販売中止のサイト変更手間と消えるリンク対応などを考慮すると、そのまま継続販売する費用対効果が高いからです。

本ブログでは、その時々に応じてテンプレート販売中止・終了予定なども記載しますが、マイコンテンプレート名が購入サイトに掲載している限り販売は継続いたしますので安心(?)してご購入ください😌。