2019-11-06

『リコールを起こさないソフトウェアのつくり方』のKindle 版リリース

リコールを起こさないソフトウェアのつくり方』のKindle 版が出ました。紙の本は絶版になってしまい、技術評論社から PDF版では買えたのですが、技術評論社の編集者にお願いして kindle 版もリリースしてもらいました。

下記は、この本が最初に出版されたときのブログ記事の抜粋です。

【『リコールを起こさないソフトウェアのつくり方』はじめにより】
日本のソフトウェア製品やソフトウェア搭載機器がグローバルマーケットで支持され続けるためには、「品質がよく割安感のある商品」を市場にアウトプットしていかなければいけないと思っています。リコールを繰り返すような品質の悪いソフトウェアではダメなのです。

一方、ソフトウェア開発の側面を見ると、欧米で体系化されたソフトウェア品質改善の方法論の多くが日本のソフトウェアプロジェクトに紹介されています。ところが、日本のソフトウェア開発現場の多くでそれらが役に立っておらず形骸化しているように感じています。また、大部分の方法論は欧米で実践されているはずですが立ち遅れているといわれる日本のソフトウェア搭載製品のほうが品質が高いという事実があります。

それはなぜなのでしょうか。それならば、日本のソフトウェアプロジェクトはこのままの方法で開発を続けていればよいのでしょうか。この命題を解明し、ソフトウェア工学をどのように日本のソフトウェアプロジェクトに適用すると有効なのかを示すことができなければ、日本のソフトウェアエンジニアは決して幸せにはなれないと思っています。これが本書を書こうと思った動機です。

本書は、たとえば、次のような方に有用です。
  •  ソフトウェア開発の初級者の方
  •  新人でこれから目指すべき道筋が見えていない方
  •  ハードウェアエンジニアで「なぜ、ソフトウェアは問題を起こすのか」を常々疑問に思っている方
  •  ソフトウェアプロジェクトマネージメントの技術を学んでいて、どうして自分のプロジェクトでうまくいかないのか悩んでいる方
  •  組織内でソフトウェア品質問題に頭を抱えている方
その他にも、ソフトウェアの品質管理、構成管理、再利用資産、安全設計などに興味を持っている方にもおもしろく読んでいただけると思います。 まず、ソフトウェアエンジニアの新人や初級クラスの方は、Part1のソースコードのケーススタディを見て、自分がいまどのレベルにいて、何を学ばないとまずいのかを考えてみてください。きっと答えが見つかるはずです。中堅、ベテランのエンジニアのみなさんは、Part1でソフトウェアの本質的な危うさを認識し、日本人の特性を理解したうえで、日本におけるプロジェクトマネージメントの適用方法を Part2で学んでください。

そして、プロジェクトリーダーやソフトウェアアーキテクトとしての責務を負っている方は、ソフトウェア再利用資産の抽出方法を Part3で修得し、現行のソフトウェア製品群の開発効率と品質向上に役立ててください。
最後に、自組織のソフトウェア製品やソフトウェア搭載製品が市場で問題を起こしており、その問題を解決する責務を負っている方は、本書の最初から最後までを通して読み、ソフトウェアと日本人の特徴を理解し、自組織において何に手をつければよいのかを理解してほしいと思います。
本書が、初級や中級のソフトウェアエンジニア、アーキテクト、マネージャ、リーダーの方にソフトウェア品質の改善活動の参考書として役立つことを期待しています。

2010 年 3月 酒井由夫
【引用終わり】

リコールを起こさないソフトウェアのつくり方』目次

Part1 ソフトウェアの危うさの本質を体感してみよう
Chapter 1 ソフトウェアの危うさを知ろう
Chapter 2 危ないソフトウェアのプログラム例とケーススタディ
Chapter 3 ソフトウェアはなぜ危ないのか
Chapter 4 ソフトウェアの品質を高く保持するために
coffee break アメリカ人と日本人

Part2 日本的ソフトウェアプロジェクトの管理はここから
Chapter 5 ソフトウェア開発の理想と現実
Chapter 6 日本のソフトウェアプロジェクトに求められる取り組み
Chapter 7 ソフトウェア構成管理
Chapter 8 ソフトウェア変更管理
Chapter 9 レビュー
coffee break 問題解決能力:自ら考え行動する力

Part3 ソフトウェア資産化の技術がリコール防止につながる
Chapter 10 ソフトウェア開発のプラットフォーム
Chapter 11 ソフトウェアシステムとソフトウェア搭載機器の価値
coffee break 3 ものづくり戦略とソフトウェア品質:品質=Qualityの話
Chapter 12 再利用資産を抽出するためのアプローチ
Chapter 13 再利用資産を抽出する手順
coffee break 4 UML導入のススメ
Chapter 14 再利用資産の抽出のケーススタディ
Chapter 15 再利用資産の抽出後のアプローチ
coffee break 5 テストカバレッジ
Chapter 16 安全性が求められるシステムに対するアプローチ
Chapter 17 安全アーキテクチャの検討
Chapter 18 ソフトウェアを資産化して品質と開発効率を高める

2019-10-20

ソフトウェア系国際規格の認証の現状について

機能安全規格の IEC 61508(Functional safety of electrical/electronic/programmable electronic safety-related systems) や ISO 26262 (Road vehicles — Functional safety )や、医療機器ソフトウェアのソフトウェアライフサイクルプロセス規格 IEC 62304(Medical device software - Software life cycle processes)に 「適合しました!」とか、「準拠しています!」といったニュースリリースをよく見る。

しかし、ブログでは『汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない』で書いたように、医療機器ソフトウェアでは、汎用ソフトウェア製品や汎用ソフトウェア製品の開発組織に対して IEC 62304 は適用できないということを解説してきた。

その趣旨は、医療機器業界では 医療機器ソフトウェアに対して主に患者のリスクを低減することを目的としてリスクベースアプローチを求めており、その考え方のもとにライフサイクルプロセスとタスクの要求を課しているため、どのような使用目的に使うのかが定まっていない汎用ソフトウェア製品に IEC 62304 を適用しようとすることは意味がないということであった。

今年2019年7月にさらなる意味がないことを示すできごとがあったので、それを説明したい。

IEC 62304 と医療機器規制との関係

まず、IEC 62304 医療機器ソフトウェア-ソフトウェアライフサイクルプロセス と医療機器規制との関係について整理しておきたい。

左図にあるように、医療機器は日本の場合、医薬品医療機器等法(通称:薬機法)で規制されており、医療機器に搭載される、または、そのものが医療機器となるソフトウェアは IEC 62304(JIS T 2304)への適合が求められる。正確には法律で国際規格が指定されているのではなく、法律が省令を省令が通知をといったようにブレークダウンされた中で IEC 62304(JIS T 2304)が医療機器ソフトウェアの要件となっている。

IEC 62304 はもちろん、医療機器製造業者が製品のソフトウェアに対して適合していることを示す必要がある。

一方で、機能安全規格 IEC 61508 や ISO 26262 は、ソフトウェア部品やソフトウェア部品を供給するサプライヤーに対しても これらの規格の一部に適合することを推奨している。

ここで注意して欲しいのは、標準規格には、強制規格と任意規格があり、ISO, IEC, JIS は任意規格であり、規制に使うかどうかは、各国の規制当局が決めるということだ。

IEC 62304 は医療機器規制の中で規制に実質的に使われている。ちなみに、IEC 26262 は今のところ規制に使われていない。ISO 26262 への適合を求めているのは、自動車OEM(メーカ)がサプライヤに対して求めているのだ。規制当局ではないから、規制要件ではない。

規格を規制に使うということは、別の見方をすれば、規格の適合を持って認可した規制当局にも責任が生じるということだ。医療機器の場合、規制当局は機器が患者危害に至るような問題を抱えていないかどうかが最大の関心事であるから、規格適合要件は、患者リスクが許容以下に低減されていることの証明でなければいけない。

ところで、自動車業界は市場規模が大きいので、ISO 26262 が国際規格となった以降、規格認証ビジネスの市場が出来上がった。

「ISO 26262 に適合しています!」というハードウェア部品やソフトウェア部品が増えてきて、ISO 26262 の適合証明を取ることが自動車業界で部品を売るための条件になりつつある。

その際、部品メーカ、特にソフトウェア部品のメーカは ISO 26262 と IEC 61508 と IEC 62304 だいたい同じだろうと考え、いっぺんに3つのプロセス規格に適合してしまえば、それぞれの業界のアピールできると考えた。

クリティカルなソフトウェアに対する規格は、どれも同じようなものだと考えた訳だ。そもそも、クリティカルなソフトウェアが安全であるかどうか確証を持って言えるわけがない。ソフトウェア起因の不具合の起こり方は特殊なので、プロセスをマネージメントして対応するしかないのだが、そのときに、どんな危害に至る可能性があるのかを想定して対応することが IEC 62304 では求められている。

だから、IEC 62304 を安全規格と分類するのはおかしい。Medical device software - Software life cycle processes(医療機器ソフトウェアのソフトウェアライフサイクルプロセス)というタイトルにあるように、IEC 62304 は 医療機器向けのライフサイクルプロセス規格であり、製品安全規格ではない。(冒頭の図を参照のこと)

ちなみに IEC 62304 は医療機器製造業者が適合を示す規格なので、ソフトウェア部品に適合証明を出すのはおかしいのに、ソフトウェア部品の製造業者に IEC 62304 の適合証明を出す 認証機関がいる。

自分は、そのような認証機関は、規格趣旨を理解していないか、もしくは、規格趣旨を理解していながら、単に金儲けがしたいために認証書を出しているのだと考えている。

そのような認証機関にはショックなできことが 2019年7月に起こった。

IEC 62304 の認証に起こったできごと

IECEE ※1 が 2019年7月26日付けの通知で IEC 62304 をCBスキームから取り下げた(Withdrawal of standards)のだ。

【※1 IECEE CBスキームについて JEITA資料より引用】

IECEE CBスキームについて
IECEEとは?
  • IEC電気機器・部品適合性試験認証制度の略称(通称CBスキームと呼ばれる)
  • IEC規格に基づく1回の適合証明試験結果を加盟53カ国(MB*)の72認証機関(NCB*)で、重複試験無しに受入れることを目的としたデータの相互活用制度
  • 制度はIECEE01(基本ルール)、IECEE02(手順ルール)及びIECEE03(CB-FCS)に 基づき運営され、これらは年1回開催されるCMC*会議にて承認のうえ改正される
  • IECEEスローガン:“One standard, one test performed anywhere, accepted everywhere !”
◆IECEEの国際法上の位置づけは?
  • WTO-TBT協定により;
  • 強制・任意分野に関わらず、国際規格・制度を適合性評価手続きの基礎とする
  • 上記手続きによって得られた評価結果は加盟国間で相互に認め合う
  • 旨の規定があり、CB制度はこれを満足するメカニズムとして認知されている

◆本制度における日本のプレゼンスは?
  • 日本は1981年にJISC(日本工業標準調査会)がMBとして加盟し、現在はJET、JQA、TUV-RhJ、UL Japanの4NCBが参加
  • 日本はIECEE国内審議委員会(事務局:JEITA)が受け皿となり、日本の対処方針を 決定のうえCMC会議に参画し意見反映


【引用終わり】

 IEC 62304 は IECEEが発行する TRF(Test Report Form)を使用し、試験を実施して適合を示すことができた。(IEC 62304の TRF が廃止されたため過去形)

 IECEE が発行する TRF(Test Report Form)を使って、CB試験所が IEC 62304 の認証を行った場合、その CBレポートは 多くの国で規制要件適合の証明として受入れられてきた。

 ところが、IECEE は IEC 62304 の TRF を廃棄してしまった。なぜか。その理由は、CB認証のルールを定めた OD-2037(関係運用文書) には「証明書Product Standardsのみ記載する」というルールがあり、IEC 62366 や IEC 62304 は Product Standardではないため、CBスコープから外されたと想像される。(予想)

 そして、冒頭の図にある IEC 60601-1 医療電気機器-第1部:基礎安全及び基本性能に関する一般要求事項 の TRF Rev.N に IEC 62304 TRF の内容が組み込まれた。

 これによって、IEC 62304 単独の CBレポートは発行できなくなった。(医療機器の安全規格である IEC 60601-1 の試験を TRF で行うと自動的に IEC 62304 のTRF の要求も満たすことになる。)

ハードウェアを含む医療機器が IEC 62304 への適合を示すには、IEC 60601-1 の TRF(現時点の最新版は Rev.N)を使用すればよい。

ただし、ソフトウェアそのものが医療機器となる単独の医療機器ソフトウェア(SaMD)では、CBレポートが発行できなくなったので、左図のプライベートレポートを使うしかなくなった。

実際、まったく独自のレポートを受け入れている国もあるので、大きな問題にはならないだろう。

また、CBスキームではなく、ISO/IEC 17025 の認定を受けた試験所で作成したレポートを受け入れる国はある。(※現時点では、日本の医療機器規制では上図のどれも受け入れている。ISO/IEC 17025 は試験所認定があるので、実質的には CBスキームの TRFレベルの試験が行われる。)

ただし、ISO/IEC 17025 の認定を受けた試験所も、IECEE が発行していた IEC 62304 のTRFを使っていたので、今後は、過去に発行されていた IEC 62304 の TRF を模倣した独自のレポートを使うことになるだろう。

今後の IEC 62304 の認証

IECEE が IEC 62304 の TRFを破棄し、IEC 60601-1 の TRF Rev.N の附属書に取り込んだことにより、CBスキームによる IEC 62304 単独の認証ができなくなったので、ソフトウェア部品メーカが IEC 61508 と ISO 26262 と IEC 62304 への適合を3つ並べてニュースリリースするケースがなくなると思われる。

そもそも、規格適合は 1. 実質的に安全や信頼が高いことを示す 2. 権威を示して売り上げを上げたい といった目的があり、規格適合を3つならべてニュースリリースしているの 2の目的だろうから、IEC 62304 が CBスキームから外れたことで、プライベート認証しかなくなり IEC 62304 単独の規格認証の権威はなくなったので、アピールもできなくなったはずだ。

今後、IEC 62304 単独の認証証を掲げる ソフトウェア部品メーカが現れたあら、それはプライベート認証であり、Intended Use(意図する使用)が定義されていないのに、IEC 62304 箇条7 ソフトウェアリスクマネジメントプロセス に適合を出してしまっているとみた方がいい。「認証」ではなく「準拠」となっている場合、おそらく箇条7が適合できていないのだろうが、箇条7ができていないということはソフトウェア開発においてリスクベースアプローチができていることが確認されていないということだから、IEC 62304 適合の意味はない。

IECEE のサイト(参照情報)




2019-08-09

Raspberry Pi3を使ったリアル波形描画(9) アーキテクチャの設計思想について

本特集記事の「Raspberry Pi3を使ったリアル波形描画」を実現するにあたり、採用したアーキテクチャの設計思想を説明しようと思う。

なお、今回より、Qt で作成したリアル波形描画のシステム(基本フレームワークだけで、フィルタや心拍検出等の中身はスケルトンにしてある)について解説するのだが、実際に動いた実績のあるソースコードを見ながら解説を読んでもらった方がよいと思う。そこで、Qt でコンパイルできるソースファイル一式と Qt の設定画面を PDF にしたものを希望する方が入手できるようにした。(Qt の設定画面を付けたのは、同じ環境にするのは意外と大変なので)

リアル波形描画のソースコード入手方法

入手方法は第一回目の記事『Raspberry Pi3を使ったリアル波形描画(1) イントロダクション』で Windows で実行できるデモファイルを配布したときと同様に、Google Drive の共有設定で共有できるフォルダにパスワード付きの圧縮ファイルを格納してダウンロードできるようにし、パスワードはメールの自動返信機能で送るようにした。

なお、最近、WEBブラウザのセキュリティが強化され、ファイルをダウンロードするときにWEBブラウザによっては、いろいろ聞いてくるようになったようだ。gmailのアドレスを持っていなくてもダウンロードできるはず。共有フォルダがからファイルをダウンロードする手順については IE11 と Microsoft Edge ではできることを確認したので、上手くいかなかったときは、これらのWEBブラウザで試して欲しい。

【リアル波形描画のソースファイルの入手方法】
次のメールアドレスに件名:ソースファイル送信 と書いてメールをお送りください。(件名は”ソースファイル送信”でなければ返信されません。メール本文は何でも構いません。
メールアドレス:CriticalSoftwareConsulting[あっとまーく]gmail.com

リアル波形描画のソースコードについて

本ソースコードは 2019年8月時点で Qt 5.12.2 / Qt creator 4.9.0 にてコンパイル・リンクし、Windows 10上で 動作しているものである。

自分のパソコンに Qtをインストールし、コンパイル/リンクして、実際に動くことを確認した上で、どのようなソースコードで動いているのか確認してみて欲しい。

どんな環境であれ、「実際に動いている」という実績は設計者に取って絶大な安心感につながる。裏返せば、ソフトウェアは一行どころか、1文字変更しただけで、システムが動かなくなるということもある。だから、一度、ちゃんと動いているという確信を得た上で、ソフトウェアを修正しては動作を確認しという作業を繰り返していれば、上手くいかなかったときに少しの後戻りでまたちゃんと動いていたところに戻ることができる。

※設計せずにコーディングをするのはダメという金言をよく聞くが、小さい実験システムでも、まずは動くコードを押さえて安心した上で、コードも設計書もきれいにするというのが自分のスタイルだ。小さいながらも「動くコード」がない状態で、設計書だけを書き進めていって実装する壁にぶつかって止まるのはイヤだ。

さて、「Raspberry Pi3を使ったリアル波形描画アプリ」のユーザーインターフェースは次のようになっている。

画面の説明







これがリアル波形描画のソフトウェアをWindows 上で実行したときの画面になる。
  1. 波形表示領域:上部の3種類のデジタルフィルタを通した後の波形。
  2. デバッグ用波形表示領域:内部処理が意図通りに動いているかどうかを確認するための表示領域。
  3. 入力ソースの切り替え(DEMO, A/D変換器, SIN波):画面に映っているのはDEMO用の三角波。
  4. 波形の切り替え(三角波1, 三角波2, 疑似心電図):三角波1 は心拍数が60になるように調節してある。入力ソースが DEMOのときのみ有効。
  5. 感度切り替え(×1/4, ×1/2, ×1, ×2, ×4)
  6. 波形掃引の開始/停止ボタン:4msインターバルと10msインターバルのスレッドを起動/終了している。
  7. 心拍数の表示:心電図のとがった部分(QRS波形)が1分間に何回計測したかをカウントして表示している。※マークはQRS波形検出時に200ms表示している。
  8. 電源ノイズフィルターON/OFF:心電図に重畳した電源ノイズ50Hz/60Hzを除去するためのデジタルフィルターのON/OFFスイッチ。ソースの中身は空となっている。(自分でフィルタを設計して実装する)
  9. ドリフトフリーフィルタON/OFF:心電図は体動などの影響で基線動揺が起こる。基線が動揺すると画面からはみ出したりして見にくいので、ドリフトフリーフィルタ(ローカットフィルタ)を入れる。ソースの中身は空となっている。(自分でフィルタを設計して実装する)
  10. ハイカットフィルターON/OFF:A/D変換前にアナログのハイカットフィルターを入れるが、それよりも低い周波数帯域のハイカットデジタルフィルター。ソースの中身は空となっている。(自分でフィルタを設計して実装する)
  11. フィルタの遅れ時間:デジタルフィルタをかけると遅れ時間が生じる。特にドリフトフリーフィルタは遅れ時間が大きい。入力波形に対して表示している波形がどれくらい遅れているのか表示する。
  12. 入力波形:フィルタ後の入力波形。
  13. 心拍検出のためのスレッショルドレベルの変化の様子:心拍数を計測するために14のフィルタ出力値のピークを計測して、そのピークを階段状に下げていき、スレッショルドレベルを設定している。(簡易的なものを実装している。このスレッショルドレベルを超えた時が新たなQRSの起点となる。)
  14. 心電図波形の微分値:心拍数を計測するために、入力波形のうち心電図のとがった部分(QRS波形)だけを際立たせるようなフィルタ(現在はサンプルで入力波形を微分して、絶対値を取っている。暫定的なもの。)をかけている。
心拍検出部分とデジタルフィルタをスケルトン(メソッドと入出力のみ実装し、中身を空にしてある)にしているのは、そこに業務ドメイン上のノウハウがあると考えているからであり、その他の部分のソースコードを公開したのは、そのアーキテクチャ自体はドメインには特化していない技術であり、学ぼうと思えばデザインパターンの本など教材は入手する方法がいろいろあるからである。

繰り返すが、もの作りをするソフトウェアエンジニアにとって、「実際に動いている」実績のあるソースコードは貴重で、「動いている」ことを確認した上で、自分自身で一から同じものを作り上げてみて、同じように「動いている」状態にまで仕上げることと、アーキテクチャを含めより理解が深まるし、自信につながる。

こちらはPC上で波形表示を行ったデモ画像


こちらは 5インチのLCD上で波形表示を行ったデモ画像

アーキテクチャの目標

今回のソフトウェアのアーキテクチャの目標は次の通り。
  1. 一発勝負ではなく、商品や商品群として10年間は骨格を変えずに使えるアーキテクチャにしたい。
  2. 変わりやすい部分(画面表示を含むUI)と変わりにくい部分(デジタルフィルタや心拍数検出の論理など)を分離したい。
  3. 心拍数計測等のアルゴリズムの改善作業を見越して、実際の生体信号の入力(A/D変換)ではなく、サンプルデータやSIN波を入力ソースとできるようにしたい。
  4. デジタルフィルタや心拍数計測アルゴリズムが意図通りに働いているかどうかをデバッグ画面で確認できるようにしたい。
  5. 普段はPC上で検討を重ね、シミュレーションで上手くいくことが検証をかさね、その後、実機でバリデーションするようにしたい。(開発効率を高めるため)
  6. タイマー制御、スレッド制御といったリアルタイム制御に関する部分は Qt で行い、作成するアプリケーションソフトウェアからはできるだけ隠蔽したい。
1回動くものができればいいという発想ではなく、商品群として長く保守や性能向上を継続し、開発効率が良く、競争力が高く、研究開発もでき、保守しやすいアーキテクチャを目指している。

ただただ早く動くものを作りたいという考え方でソフトウェアの開発を続けていくと、開発効率は上がらず、過去の作ったソフトウェアの保守に追われるという悪循環から抜け出すことができない。

そのような負のスパイラルから脱却するためには、長持ちして、競争力が高く、保守もしやすいアーキテクチャを目指す必要がある。

実現の可能性(Feasibility Study)の結果

上記の目標を実現するのに重要な「実現可能性」のポイントは、Qt で正確なタイマ割り込みを発生させ、かつ、優先度の高いスレッドと低いスレッドを走らせることができるかどうかだった。

Raspberry Pi3B+ のCPU は ARM Cortex-A53 1.4GHz でクワッドコア(CPU4つ)なので、4ms の定期割り込みの発生など、CPUスペックから考えれば楽勝と思えるのだが、そう簡単にはいかない。

なにしろ、Linux はリアルタイムOSではないし、OSの制限もあり、msオーダーの定期割り込みを発生させるのは簡単ではない。

さらに、このシステムを実現するには、マルチスレッドが必須であり、かつスレッド間のデータの受け渡しが必要で、これが意外に難しい。

でも、Qt の SIGNAL/SLOT のしくみを使うことによって、マルチスレッドとイベントの伝達、データの受け渡しができることが分かった。

ただ、できれば、CPUコアが4つあるので、4msインターバルの割り込み処理を行うスレッドは4つのコアのうち一つに割り当てたかったのだが、Qt 上でその設定ができなかった。

その代わり、定期インターバルの起動間隔に大きなバラツキが発生したいないことは、常に確認できるようにした。

10ms 間隔で起動されるスレッドで、システムタイマーの値を読み込んで、前回のタイマーの値との差分を printf で表示するようにしてある。下記は Windows で走らせたときの様子だ。これを Raspberry Pi3B+ で実行したときも、間隔に大きなずれがなければ、定期割り込みは成功していることになる。ちなみに、下記の例ではインターバル間隔に 0.5% 程度の誤差(ジッター)がある。この誤差がシステムとして許容できないようならば、Raspberry Pi3B+ の外側で発生させるか、Raspberry Pi3B+ にリアルタイムOS を搭載する。今回は、できる限り、ハードウェアの追加なしで実装したかったので、0.5%のジッターは許容したが、常にブレが大きくなっていないかどうかをWatchしておくことは重要だ。

time: 1475803.318404771 CLOCK_REALTIME 09987 DIFF:uSec
time: 1475803.328394707 CLOCK_REALTIME 09989 DIFF:uSec
time: 1475803.338389771 CLOCK_REALTIME 09995 DIFF:uSec
time: 1475803.348481033 CLOCK_REALTIME 10091 DIFF:uSec
time: 1475803.358499317 CLOCK_REALTIME 10018 DIFF:uSec
time: 1475803.368381897 CLOCK_REALTIME 09882 DIFF:uSec
time: 1475803.378349216 CLOCK_REALTIME 09967 DIFF:uSec
time: 1475803.388392228 CLOCK_REALTIME 10043 DIFF:uSec
time: 1475803.398597482 CLOCK_REALTIME 10205 DIFF:uSec
time: 1475803.408382657 CLOCK_REALTIME 09785 DIFF:uSec
time: 1475803.418337612 CLOCK_REALTIME 09954 DIFF:uSec
time: 1475803.428369466 CLOCK_REALTIME 10031 DIFF:uSec
time: 1475803.438366942 CLOCK_REALTIME 09997 DIFF:uSec
time: 1475803.448362910 CLOCK_REALTIME 09995 DIFF:uSec
time: 1475803.458338070 CLOCK_REALTIME 09975 DIFF:uSec
time: 1475803.468366909 CLOCK_REALTIME 10028 DIFF:uSec
time: 1475803.478349608 CLOCK_REALTIME 09982 DIFF:uSec
time: 1475803.488375431 CLOCK_REALTIME 10025 DIFF:uSec
time: 1475803.498362352 CLOCK_REALTIME 09986 DIFF:uSec
time: 1475803.508351083 CLOCK_REALTIME 09988 DIFF:uSec
time: 1475803.518362431 CLOCK_REALTIME 10011 DIFF:uSec
time: 1475803.528348146 CLOCK_REALTIME 09985 DIFF:uSec
time: 1475803.538355272 CLOCK_REALTIME 10007 DIFF:uSec
time: 1475803.548384713 CLOCK_REALTIME 10029 DIFF:uSec
time: 1475803.558325194 CLOCK_REALTIME 09940 DIFF:uSec
time: 1475803.568313623 CLOCK_REALTIME 09988 DIFF:uSec
time: 1475803.578347889 CLOCK_REALTIME 10034 DIFF:uSec
time: 1475803.588317923 CLOCK_REALTIME 09970 DIFF:uSec
time: 1475803.598452309 CLOCK_REALTIME 10134 DIFF:uSec
time: 1475803.608321620 CLOCK_REALTIME 09869 DIFF:uSec
time: 1475803.618302208 CLOCK_REALTIME 09980 DIFF:uSec

ちなみに、この部分を実験したのが『Raspberry Pi3を使ったリアル波形描画(6) Qtでマルチスレッド処理をやってみる』の記事になる。 この実験によって、およそQt上で4ms と 10ms の間隔のタイマー割り込みを発生させ、マルチスレッドで優先度の高いスレッドにタイマー割り込み処理を任せることができた。(目標6) その確認なくして、Qtを使ったリアル波形描画 の構想はありえないし、意味がない。

 また、Qt そのものの特長により、マルチプラットフォームでの開発と、UI部分の開発効率を高めることができることも分かった。(目標2,5) 以前の記事でアーキテクトは「実現の可能性(Feasibility Study)」について「いける!」という感覚をつかめるかどうかが重要だと言うことを書いた。 「実現の可能性(Feasibility Study)」について「いける」のか「いけないのか」を判断するには、その商品に対して求められている要求と要求の優先度が頭の中に入っており、その要求を実現するための実現方法の引き出しをたくさん持っている必要がある。

要求はさまざまあり、全部実現しようとするとコストが上がったり、開発の時間が足りなくなったりするので、競争力の高い商品にするためには、どの部分に独自の研究開発のリソースをつぎ込んで、どの部分はすでにある技術や市販のソフトウェアで補うのか、一番いいバラインスポイントを探す必要がある。

それには深いドメイン知識と、広いソフトウェアエンジニアリングの技術、豊富なソリューションの引き出しを持っていることが大事だ。

ちなみに、オブジェクト思考設計のコンサルタントは「広いソフトウェアエンジニアリングの技術」、「豊富なソリューションの引き出し」を持っているが、「深いドメイン知識」はない。一般的に組込みソフトウェア製品の企業のエンジニアは「深いドメイン知識」を持っているが、「広いソフトウェアエンジニアリングの技術」と「豊富なソリューションの引き出し」を持っている者は少ない。

よって、長持ちして、競争力が高く、保守もしやすいアーキテクチャを目指すためには、両者が協力するか、企業のエンジニアががんばって知識やスキルを身につける必要がある。

なお、ドメイン知識として、ユーザーまたは業務ドメインにおける市場要求の分析は、製品企業側で分析しておく必要がある。お客さんの声を吸い上げることができるのは、製品を設計販売している企業であり、そこに実現すべき機能や性能のもととなる要求がある。

要求の整理についてはQFD(品質機能展開。左図が一例)などを使うとよい。または、マインドマップなどで整理してもよい。 それらの要求が実現可能かどうかは、さまざまな条件(コスト、リソース、エンジニアが使いこなせるかどうか等々)があるので、単純ではない。なにしろ幅広い知識(引き出し)と、最新の情報にアンテナを張っていることが必要になる。 今の世の中情報はあふれかえっているので、やりたいこと、実現したいことは常に頭の中に記憶しておいて、やりたいことの実現に関係ある情報を見つけたら、その情報をクリップしておいて掘り下げるという習慣を付けておく必要がある。 働き方改革で、オンとオフをキッチリ分けて休むときは休んでエネルギーを充電するのはいいと思うが、アンテナはオフのときも立てておいて、実現可能性の種がピピッときたらメモっておくぐらいのとをやっていないと、なかなか競争には勝てない。

静的構造の説明(3層構造)



さて、「Raspberry Pi3を使ったリアル波形描画」のアーキテクチャ(静的な構造、クラス図)について説明していこうと思う。 なお、このアーキテクチャについては今回記事の冒頭でソースコードを入手できるようにしてあるので、ソースコードを見ながらクラス図を眺めて欲しい。

デジタルフィルタと心拍数検出のアルゴリズムについては、それぞれソースコードはインタフェースだけ用意してあり、中身は空または簡易的なものにしてある。(ここが最も重要なノウハウ=コア資産と考えているため)

この部分の性能を高めることができれば、他社に対する競合力となり、その資産は組織の財産となる。また、その資産が真似しにくい若しくは特許で保護されていれば、商品群のコア資産として商品の価値を生み出す宝となりうる。

 このアーキテクチャは プレゼンテーションレイヤー、ドメインレイヤー、データソースレイヤーの3層構造となっている。 プレゼンテーションレイヤーは、ユーザーとのユーザインタフェースを担う部分であり、表現方法は商品群の中でも変わりやすい(ハイエンド製品は大画面、ローエンド機器は小画面など)。逆に言えば、プレゼンテーションレイヤー部分を変えることで、ラインナップを揃えたり、マイナーチェンジをして商品を新しく見せることができる。

仕向け地や特別なユーザー用にカスタマイズすることもあるかもしれない。 プレゼンテーションレイヤーは変わりやすく、変化に柔軟に対応できるようにしておく必要がある。

プレゼンテーションレイヤーの部分の変化に対する対応は Qt Creator を使うことで、簡便にいろいろな画面を実現することが可能だ。

また、ドメインレイヤーは、その商品あるいはその商品群に特有の資産を配置している。ドメインに特化しているため、その商品の本質的な機能や性能を実現していることが多い。別な言い方をすれば「本業の強み」を実現する部分だ。場合によってはソフトウェアだけでなくハードウェアも含めてコア資産となる場合もある。 基本、このドメインは「変わりにくい部分」であり、ノウハウとなり得る。

なお、今回のケースでは、黄色背景のタイマー処理とスレッドのクラスもドメインレイヤーに配置した。これらはドメインに特化したクラスではないものの、プレゼンテーションレイヤーやデータソースレイヤーとも異なり、リアルタイムシステム実現のための要素でり、システム実現の根幹と考えたからである。

データソースレイヤーはその名の通り、システムが使用する入力データの元となるレイヤーであり、ここは、 EcgAcquirer (心電図の受入れ者)から派生させた、3つのクラスを実装している。 その意図は、入力クラスのインタフェースを共通にしておき、入力元の実態を A/D変換器と、サンプルデータと sin波 の3種類で切り替えることができるようにしている。 信号処理アルゴリズムの設計、性能分析、性能向上を検討するためには、リファレンスとなる波形データや、問題が起こったときの 波形データをファイルから読み込んでシミュレーションでさまざまな確認を行うことが重要となる。

アルゴリズムを変更したときなど、今まで動いていた機能や性能が、意図通りに動いているかどうかを確認することはとても重要であり、その確認・検証には、検証に使うシミュレーション用のデータがあるとよい。そのための入力切り替えでもある。

また、デジタルフィルタの効き具合を確かめるのに、シミュレーションでsin波を入力できると都合がよい。 入力の切り替えのしくみは、C言語でも条件コンパイルを駆使したりして実現は可能だが、オブジェクト指向言語であるC++を使えば、スマートに実現できるし、クラス図でその設計思想を表現するのもやりやすい。

実際、このクラス図も、Qtで設計して上手くいくことを確認したC++のソースファイルを UMLツールである Enterprise Architect に読み込ませて、整えることでクラス図にした。 そうすれば、実際のソースコードの設計思想を正確にクラス図で表現できるからだ。 入力の切り替えは、紫背景のQt Creator で作成したボタンの押下をトリガーにして、緑背景の EcgMonitor で入力のオブジェクトインスタンスを入れ替えることで、簡単に切り替えることができる。 これができると非常に気持ちがいい。また、入力のインタフェースが変わらなければ、さらに別の入力例えば、既存の心電図データベースを追加することもできる。
る。

Qt Creator の画面

左記が QtCreator で RealWaveDisplay01 のプロジェクトファイルを開いたときの画面である。ざっと、ソースファイルの説明をしておく。

まず、頭に ap_ がついているファイルは、リアル波形描画特有のアプリケーションを意味する。

qt_ がついているファイルは、Qt に特化した部分、今回は周期起動するスレッド処理。

qcustomplot.h と qcustomplot.cpp はオシロスコープのように右から左に波形を流すために使っているソースで、『Raspberry Pi3を使ったリアル波形描画(3) Qt + QCustomPlot で静止グラフを描いてみる』の記事の一番下に使い方の解説動画がある。

main.cpp は Qt のお決まりの入り口関数で、mainwindow.h と mainwindow.cpp は Qt のメインウインドウの画面の初期化やら、画面で使っている変数や、ボタンが押されたときの処理のメソッドなどが入っている。

アプリケーションのソフトウェアのファイルの説明は次の通り。
  • ap_EcgAcquirorFromSampleData.cpp :DEMO波形のデータ
  • ap_EcgAcquirorFromADConvertor.cpp :A/Dコンバータからの入力(現在スケルトン)
  • ap_EcgAcLineNoiseFilter.cpp :電源ノイズフィルター(現在スケルトン)
  • ap_EcgHighCutFilter.cpp :ハイカットフィルター(現在スケルトン)
  • ap_EcgDriftFreeFilter.cpp :ドリフトフリーフィルタ(現在スケルトン)
  • ap_EcgMonitor.cpp:波形計測の中心となるクラス(各種オブジェクトの生成も行う)
  • ap_EcgAcquirorFromSinWave.cpp:SIN波発生
  • ap_EcgDetectQrsTypeTest1.cpp:QRS検出(簡易的なアルゴリズムにしている)

mainwindow.cpp の説明

mainwindow.cpp 内の MainWindow クラスは QMainWindow クラスから派生したクラスでヘッダは次のようになっている。

class MainWindow : public QMainWindow
{
    Q_OBJECT
public:
    // コンストラクタ
    explicit MainWindow(QWidget *parent = nullptr);
    // デストラクタ
    ~MainWindow();

    // グラフ初期化
    void intializeGraph();

private slots:
    // Run/Stop ボタンを押された時の処理
    void on_pbt_run_clicked();
    // 波形タイプボタンを押された時の処理
    void on_pbt_wavetype_clicked();
    // 電源ノイズフィルターボタンが押された時の処理
    void on_pbt_ac_line_filter_clicked();
    // ドリフトフリーフィルタボタンが押された時の処理
    void on_pbt_drift_free_filter_clicked();
    // ハイカットフィルタボタンが押されたときの処理
    void on_pbt_hicut_filter_clicked();
    // 表示感度ボタンが押された時の処理
    void on_pbt_displaygain_clicked();
    // 入力ソースボタンが押されたときの処理
    void on_pbt_input_type_clicked();
    // 周波数スピンボックスの値が変化したときの処理
    void on_doubleSpinBox_frequency_valueChanged(double arg1);

public slots:
    // 4ms周期処理
    void work4msPeriodicOnMainWindow(void);
    // 10ms周期処理
    void work10msPeriodicOnMainWindow(void);
private:
    Ui::MainWindow *ui;

    CyclicThread *mpCyclicThread4ms     = new CyclicThread;      // 周期起動のスレッドオブジェクト(プライベートメンバ変数)
    CyclicThread *mpCyclicThread10ms    = new CyclicThread;      // 周期起動のスレッドオブジェクト(プライベートメンバ変数)

    float mTimekey_wave = 0;                        // 波形表示間隔 (s)
    float mWave_data = 0;                           // 波形データ
    float mAdd_data = 0.1F;

    float mTimekey_debugwave=0;                     // デバッグ用波形表示間隔
    float mQrsFilterWave_data=0;                    // QRSフィルt出力用波形データ
    float mThresholdLevel_data=0;                   // スレッショルドレベルデータ

    unsigned short mDisplayCounter=0;               // ディスプレイ用のカウンタ(10msの倍数で表示する)

    bool mRunStopFlag = false;                      // Start/Stop フラグ

    unsigned short mEcgDemoCounter=0;               // 心電図デモカウンター
    unsigned short mDemoWaveType=0;                 // デモ波形タイプ0:三角波 HR60 1:三角波 HR300 2:疑似心電図,);
    float mMaxWave=0;                               // 最大波形
    float mMinWave=0;                               // 最小波形
    float mPreviousPlotData=0;                      // 前回のプロットデータ

    bool mRealWaveFlag=false;                       // リアル波形<->デモ波形スイッチ

    // 心電図モニタクラスを生成
    EcgMonitor  *mpEcgMoniter = new EcgMonitor;     // 心電図モニタクラス

    bool mAcLineFilterFlag;                         // 電源ノイズファルタフラグ
    bool mDriftFreeFilterFlag;                      // ドリフトフリーフィルタフラグ
    bool mHicutFilterFlag;                          // ハイカットフィルターフラグ
    unsigned short mHRDisplayCounter;               // ハートレート表示用カウンタ(1秒)
    unsigned short mQrsMarkDislpayCounter;          // QRSマーク表示用カウンタ
    bool mQrsMarkDislpayFlag;                       // QRSマーク表示用フラグ

    unsigned short mDisplayGain;                    // 表示用の感度変数
    char mGainText[5][6]={("x1/4"), ("x1/2"),("x1  "),("x2  "),("x4  ")};
    unsigned short mInputType;                      // 入力種別
    char mInputTypeText[3][18]={("Demo             "),
                                ("A/D Convertor    "),
                                ("Sin Wave         ")};
    double mFrequency;                              // sin波の周波数

};

頭が on_pbt_・・・ となっているメソッドは、画面上でボタンが押されたときに、呼ばれるメソッドとなる。

各種変数の定義と初期化、4msと10msの周期起動のスレッドの生成、心電図モニタメインクラスの生成などを行っている。(青字部分)

入力の切り替え


入力の切り替え部分を説明する。登場人物の説明
  • EcgAcquirorクラス:心電図入力の基底クラスで実態を持たない。
  • EcgAcquirorFromADConvertor:EcgAcquirorクラスから派生したクラスで、A/D変換器からの入力を意図している。(公開ソースでは、スケルトンにしてある)
  • EcgAcquirorFromSampleData:EcgAcquirorクラスから派生したクラスで、データで定義したサンプルデータ(三角波二種類と疑似心電図データ)を供給することを意図している。
  • EcgAcquirorFromSinWave:EcgAcquirorクラスから派生したクラスで、SIN波のデータをEcgMonitorクラスに供給することを意図している。
EcgAcquiror は 心電図入力の基底クラスで getEcgWaveData() を純粋仮想関数にして、心電図波形データの入力ソースを切り替えられるようにしている。

EcgAcquiror 入力のインタフェースを固定しておき、EcgAcquiror クラスから 派生させた入力ソースのクラスから、さまざまなデータを EcgMonitor クラスに共有する。

EcgAcquirorFromADConvertorクラス以外は、実機(製品)では使わないのだが、デジタルフィルタや心拍計測アルゴリズムの検証したり、デモンストレーションしたりするときに、EcgAcquirorFromSampleDataクラスや、EcgAcquirorFromSinWaveクラスはあると便利だ。

また、例えば、実際にA/D変換して取り込んだ心電図データや、いろいろな心電図のデータライブラリをファイルから読み込むような時には、EcgAcquirorクラスから派生させたクラスを新たに作成して、EcgMonitor クラスに持たせれば 簡単かつ、安全に入力ソースを追加することができる。

この「簡単かつ安全に追加できる」ということがオブジェクト指向言語である C++ を使う目的であり、組込みソフトウェアでも C言語にこだわっている時代ではないと思う理由だ。C言語でも同じことはできると思うが、「簡単かつ安全に追加する」ためにはC++を使った方がよいと思う。

具体的には EcgMonitor クラス のメソッドに 心電図入力オブジェクトのポインタ変数を作っておき、派生させた3つのクラスを new で作成してそれらのポインタをポインタ変数に格納している。

protected:
    // 心電図入力オブジェクトのポインタ(メンバ)をする
    EcgAcquiror *mpEcgAcquiror;
    EcgAcquirorFromSampleData   *mpEcgAcquirorDemo  = new EcgAcquirorFromSampleData;
    EcgAcquirorFromADConvertor  *mpEcgAcquirorADC   = new EcgAcquirorFromADConvertor;

    EcgAcquirorFromSinWave      *mpEcgAcquirorSin   = new EcgAcquirorFromSinWave;


void EcgMonitor::activateEcgDemoMode(void)
{
    // 心電図入力オブジェクトにデモ波形オブジェクトを設定して、デモタイプを三角波にする
    mpEcgAcquiror       = mpEcgAcquirorDemo;
    mpEcgAcquirorDemo->setEcgDemoType(0);

}


void EcgMonitor::activateEcgAdcMode(void)
{
    // 心電図入力オブジェクトにADCオブジェクトを設定する
    mpEcgAcquiror       = mpEcgAcquirorADC;

}


void EcgMonitor::setEcgDemoType(unsigned short type)
{
    if ( type > 2) type = 0;        // 3以上だったら強制的に 0:ECGにする

    // 波形種別を設定する。
    mpEcgAcquirorDemo->setEcgDemoType(type);

}


そして、入力モードの切り替えが指示されたら、mpEcgAcquiror に各、入力ソースのポインタをセットしてあげればよい。

それだけで、その後の処理は何も変える必要がない。

   //----------------------------------------------
    //     内容:疑似心電図三角波
    // サンプリング: 4ms
    //   データ数: 250
    //     振幅:1000
    //----------------------------------------------
    // HR = 60のデータ
        {
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.000 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.010 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.020 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.030 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.040 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.050 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.060 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.070 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.080 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.090 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.100 
               0, 100, 200, 300, 400, 500, 600, 700, 800, 900, // No.110 
            1000, 900, 800, 700, 600, 500, 400, 300, 200, 100, // No.120 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.130 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.140 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.150 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.160 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.170 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.180 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.190 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.200 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.210 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.220 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0, // No.230 
               0,   0,   0,   0,   0,   0,   0,   0,   0,   0 // No.240 

        },

サンプルデータはこんな感じでデータが定義されている。

そして、このような切り替え可能な構造になっていいることは、作成したソースコードを UML ツールに読み込んで、整形して クラス図にすることで、モデルで確認することができる。

それが、上記のクラス図だ。クラス図を描いてからソースコードを作ったり、ソースコードをリバースエンジニアリングしてクラス図を作ったりを繰り返していると、だんだん派生のしくみや、クラス図どおりに実装するにはどうすればよいかが分かってくる。

次回以降は、入力部以外のアーキテクチャを解説していく。

2019-06-10

Raspberry Pi3を使ったリアル波形描画(8) アーキテクトの腕の見せどころ

この特集記事とは別に『ソフトウェアアーキテクチャとは何かを考える』という記事を書いた。

ここで説明したのはリアル建築で例えれば「どんな生活をしたいのか」「家主の要望は何か」「予算はどれくらいか」などによって,家の構造設計は変わるということだ。

ソフトウェアのアーキテクチャも何をしたいのか,どんな困りごとを解決したいのかによって,ソフトウェアシステムのアーキテクチャは変わる。ソフトウェアのアーキテクチャの重要なポイントは「設計思想」だと思う。設計思想こそが「アーキテクトの腕の見せどころ」のポイントなのだ。

ソフトウェアアーキテクチャとは何かを考える』にも書いたが,ソフトウェアの場合は,「大改造!!劇的ビフォーアフター」のようにリフォーム後に アーキテクトの仕事の成果を顧客とともに見て回り,リフォームのできに感動してもらうといったシーンがない。ソフトウェアは見えないから,アーキテクチャの善し悪しは分かる人にしか分からない。そこがなんとも悲しいところなのだが,だからこそ,アーキテクトはそのシステムのアーキテクチャの設計思想を他人にキチンと説明できるようにしておかないとダメなのだろう。

そう思い,今回の記事では 『Raspberry Pi3を使ったリアル波形描画』の取り組みの中で採用しようとしているアーキテクチャの設計思想を説明しておきたいと思う。

考え方はInterface誌 2003年1月号に投稿した記事『オブジェクト思考を使ったリアルタイム信号計測システムの開発』と同じなので,まずは,この記事で想定した 1ch のデジタルオシロスコープを例に説明しようと思う。

ここに 1ch のデジタルオシロスコープの完成予想図がある。この機器の目的は,電気回路の信号をピックアッププローブで拾って,高周波のノイズを取り除いて,目的の信号だけを見えるようにして,結果をUSB経由でPCに保存するというものだ。

この製品のソフトウェアシステムを設計したい。設計の前に解決したい問題を確認しておこうと思う。

解決したい問題

この商品の開発の前提として,この商品は単発の商品とするのではなく,商品ラインナップにして,基本の機能はさまざまなオシロスコープ製品群に使いたいと思っている。

この商品の基本機能はノイズを除去するためのデジタルフィルターであり,ハイエンド製品では,さまざまな,フィルターを搭載できるようにしたり,切り替えたりできるようにしたい。よいデジタルフィルターを設計し,搭載することができれば,それがこの商品群のコア資産となり,その資産が他社の商品と競合したときのアドバンテージとなる。

したがって,アーキテクチャの第一の目的は「コア資産となるデジタルフィルタのソフトウェアモジュール」の再利用しやすく設計し,さまざまな商品群にソフトウェアにまったく手を加えることなく※1,利用できるようにすることである。

※1 コア資産の主要部分(パラメータ設定以外)についてはソースコードを1行も変更しないで複数の製品に使用できることを「再利用」と言っている。ソフトウェアは簡単に変更することができ,1行変更しただけで動かなくなったり,デグレードしたりするので「再利用」は基本,ソースコードの変更はなしでできることが前提。

それがうまくいけば「競争力の高いソフトウェア資産」使って,さまざまな商品展開ができ,顧客満足が高まり,商売も儲かる。

また,「競争力の高いソフトウェア資産」に問題があり,それが市場で発覚すると,組織に大きなダメージを与えるため,コア資産となるソフトウェアの信頼性は十分に確認しておきたい。これらの要求をまとめると次のようになる。
  1. コア資産となるデジタルフィルタのモジュールを再利用可能な資産(ソフトウェア本体にまったく手を入れることなく再利用可能)にする。
  2. コア資産となるデジタルフィルタはさまざまなバリエーションを持たせる。
  3. 新しいフィルタを開発することと,採用するフィルタの妥当性確認(バリデーション)をしやすくするために,実機ではなくPC上でフィルタ効果を確認できるようにしたい。
  4. フィルタの入力は信号ピックアッププローブから入力するだけでなく,検証用に持っている信号データや,擬似的に作成したデータを入力できるようにしたい。
  5. データの保存はUSB経由を想定しているが,将来は Wi-Fi や ブルートゥース経由でPCへ保存できるようにしたい。
ちなみにソフトウェアの「再利用」ではなく「流用」ということばを使っている技術者をよく見かけるが,自分は「流用」ということばは絶対に使わない。「流用」ということばの響きに「再利用のための設計思想はありません」というニュアンスを感じるからだ。

設計思想のないアーキテクチャには将来ろくな事がないと思う。設計思想なく「流用」されたソフトウェアは,最初に設計したときの思想が伝わることなく,別のシステムにはめ込まれ,予想もしなかったような不具合が起きることがある。

さて,これらの要求を実現するための概念的な構造を図で表してみると左図のようになる。(設計の思想)

入力は製品では信号ピックアッププローブから入力(A/D変換)するが,実験,検証のために信号データファイルからも入力できるようにしたい。

この入力の切り替えは簡単にスイッチできるようにしたいし,その後のソフトウェア(デジタルフィルタやディスプレイ表示やデータ保存)には影響を与えたくない。(1行もソフトウェアを変えないで済むようにしたい)

信号処理部のデジタルフィルターは,さまざまなものをラインナップし,こちらも簡単に切り替えられるようにしたい。新しいフィルタも簡単に試せるようにしたい。

波形の出力は 小さなLCDディスプレイに表示するが,このLCDディスプレイは商品によってサイズや解像度が変わる。また,後継機種を出す際にはLCD部品が変わる可能性が高いので,これらの変化に柔軟に対応できるようにしたい。

さらに,データの出力機能としては,当初は USB I/FでデータをPCに送るが,将来はWi-Fi や ブルートゥース経由でデータを格納できるようにしたい。

このシステムにおけるコア資産は何か?変わりない部分と変わりやすい部分

この商品または商品群における「コア資産」はデジタルフィルタA, B, ・・・ Z である。これらは有効性が確かめられれば,今後,ずっと代えることなく使い続けることのできる資産である。長い間変わりのない部分となる。そして,ずっと変わらず性能がよければ他社との競争力の源泉にもなる。これらのコア資産を最大限活かすことが,今回のアーキテクトの設計思想(腕の見せどころ)だ。

なお,出力部のLCDディスプレイは変更となる可能性が高い。また,出力の I/F は時代とともに新たなものが増えていく。ようするに,将来の商品開発を見据えて長い目でみれば,変わりやすい部分と言える。

変わりやすい部分の影響を受けて,コア資産にも変更が加わるようにはしたくない。ソフトウェアアーキテクチャ上,信号処理部と出力部はキッチリ分けて,信号処理部から出力部へのデータ渡しの I/F はできるだけ変わらないようにしたい。

また,入力部の信号ピックアッププローブと信号データファイルについても,その後ろの工程からみたらその差について気にしないですむようにしたい。


信号ピックアッププローブと信号データファイルの切り替えのイメージはこのような感じとなる。

製品では A/D変換器から取り込んだ信号でデータにデジタルフィルタをかけ,結果を表示する。

これをリアルシステムとすれば,バーチャルシステム(仮想システム)では,信号データはファイルたか取り込んで,デジタルフィルタをかけ,その結果を開発マシンのPCのディスプレイ上に表示したい。

「バーチャルシステムでコア資産の性能を検証し,商品として使えそうであること(有効性)が確認でき次第,コア資産のソフトウェアに手を加えることなく,リアルシステムで動かす」これが,今回のシステムの設計思想となる。

ちなみに,コア資産は変わりにくいとはいえ,一度作ったら終わりということにはならない。競合他社と競争しているわけだから,日々改善,性能向上をしていく必要もある。そのき,改善したコア資産の中身だけを入れ替えて,コア資産の入力と出力のI/Fを代えなくて済めば,安全に性能向上のバージョンアップができる。

コア資産の改善と,入出力の仕様の変化の対応を同じレベルで考えてはいけない,コア資産の改善は,その商品や商品群の屋台骨を強くするための取り組みであり,入出力の仕様の変化に対応するのは,ユーザインタフェースの改善が目的である。後者は商品の本質的な価値に関係し,後者は商品の(表面的な)魅力に関係する。どちらも,商品が売れるためには必要だが,コア資産は他社にまマネできない競争力の源泉であり,後者は他社が真似しようと思えば真似できる。だから,コア資産は機能や性能を確認し,信頼性が十分に高い状態を維持し,ユーザインタフェースの部分は時代に合わせて素早く変化できるよにしておくことが重要となる。

コア資産の性能向上を検討したときに,デグレード(今までできていたことができなくなったり,性能が落ちたりすること)してはまずいので,これまでできていたことの検証もできるようにしておきたい。

そのとき,実機でさまざまな入力信号を再生して,結果を確認するのは多大な工数を必要とする。だから,この検証部分は バーチャルシステムで網羅性の高い確認を行い,最後にリアルシステムでサンプル検証する方法を採りたい。

これらができると飛躍的に開発効率が高まる。
  • 新しい性能(今回はフィルタの特性)の確認が実機なしで確認できる。
  • さまざまな入力データを新しいコア資産に通した結果をシミュレーション環境で確認できる。
  • ソフトウェアをいじることなく,かつ,安全に新しいコア資産をリアルシステムに実装できる。
  • フィールドで問題が起きたとき(例えば,結果が期待通りにならないケース)入力データを記録できれば,そのデータを繰り返しシミュレーション環境で再現できる。

これを図で示すとこんな感じとなる。

仮想システムでコア資産となるデジタルフィルタにサンプルデータを流し込み,開発環境のPCのディスプレイに表示する。

このとき,デバッグ用に内部データをPCに表示することも可能。

そして,さまざまな入力データで網羅性の高い検証を行ったのち,リアルシステムにスイッチして実機環境にて,シミュレーション環境と結果が同じになることを確認して実装を完了する。

今回のシステムでやりたいことは,こういったことだ。

ここまでの説明でお分かりかと思うが,ソフトウェアのシステムアーキテクチャの設計にあたって,対象の商品や商品群,提供するサービス,顧客の要望,開発効率を妨げていることなどの情報が必要となる。

そして,商品や商品群のコア資産が何か,そのコア資産を再利用して効率よくまた,安全に派生開発できるようにするには,どんなアーキテクチャが最適かを考える。

ソフトウェア開発を単発で考えているとこの発想にはならない。製品のソフトウェアを外部の協力会社に丸投げしているようなプロジェクトでは,およそこういった発想にはならないだろう。商品開発とソフトウェアの再利用,開発の効率化,安全性信頼性の向上を頭にいれたアーキテクチャ設計が必要になる。

5年とか10年,また,複数の商品,商品群で共通に利用するコア資産をベースにした再利用開発を想定したアーキテクチャ設計を行う,これがソフトウェアアーキテクトの腕の見せどころとなる。

このようなシステムを実現するためのソフトウェアアーキテクチャは具体的にどう設計するのかを次回以降解説する。

今回の記事には書かなかったが『Raspberry Pi3を使ったリアル波形描画(6) Qtでマルチスレッド処理をやってみる』に書いたように,マルチスレッドによる正確なタイムインターバルの実現と,タイマーイベントとデジタルフィルタのモジュールはパッシブに(『ソフトウェアアーキテクチャとは何かを考える』で解説したデータ結合のような疎結合状態)つながるようにしないといけない。

また,デバッグ用の画面も含めたユーザインタフェースはゼロから作るのは効率が悪い。今の時代,さまざまなお助けツールがある。

今回の特集記事で Qt を使った事例を書いているのは,ここまで説明してきたアーキテクチャの基本設計の方針を Qt を使うと上手に実現できそうだということが分かったからだ。(特にユーザインタフェースの部分は相当お助けになる)

波形描画やボタンなどのユーザインタフェースは自分で作ると結構時間がかかる。しかも,UIは時代とともにどんどん変わっていくし,ユーザもリッチなUIに慣れてきているので,プアーなUIだと中身の性能が良くても,商品として評価が低くなるかもしれない。

だから,Qt を使うことでユーザインタフェースは最大限作業を省くことができたし,デバッグ用の内部のデータ表示なども,サクッと作ることができた。

そして,PC上で表示した画面をソースコードを変えることなく,そのまま,Raspberry Pi3 上で使えるのも魅力的だった。

さらに,4ms の正確なタイムインターバルを発生させて,Qt のSIGNAL/SLOTのしくみをつかって,他のコア資産にイベントを伝達できることも分かった。

ソフトウェアアーキテクチャの設計思想がよくても,実現の方法や条件が満たされていないと上手くいかない。さまざまな制約条件をクリアしつつ,目的のアーキテクチャを設計思想通りに実現する,これがソフトウェアアーキテクトの腕の見せどころなのだ。

制約があればあるほど,燃えるのがプロの職人であり,そのためには,数多くの経験とソフトウェア設計に関する多くの引き出しがないといけない。いろいろな制約条件がある中で,設計思想にぴったりくるアーキテクチャが見つかったときに「いける!」と感じる瞬間がある。

それは,開発の相当初期の段階で,実現可能性の検討段階(フィージビリティ・スタディ)のときでないとまずい。作り始めてしまったあとに,最初の設計思想が実現できないことがわかり,妥協していくと,グダグダになってプロの仕事でなくなってしまう。

制約条件をクリアしながら,価値の高い商品を効率良く生み出していくアーキテクチャ,これを実現するのがプロのソフトウェアアーキテクトだと思う。

今回,ソフトウェア自体(ソースコードやクラス図など)に一切触れなかったのは,アーキテクチャを決定するのに,いかに設計思想が重要かということを理解してもらいたかったからだ。

プログラマーとしてプロならば,デザインパターンなどの定石や手筋が習得できているだけでいいのかもしれないが,ソフトウェアアーキテクトしてプロの仕事をするのならば,効率良く儲かる,ユーザにも高い満足を与えることができる設計が必要だ。

リアル建築に例えれば,一級建築士の資格をもって,個人事務所を持ち,限られた予算でさまざまな要求を持つ顧客を満足させる家を実現するために最適な図面を書き,設計思想どおりに家ができるようにコントロールする役割が求められる。

同じ要求のユーザはほとんどいない。業務ドメインによって,求められる構造も,制約条件も変わる。今回紹介しているリアル波形描画のシステムにしても,ドメインに依存しており,処理の時間制約が厳しいという条件に特化していると言える。

だから,このアーキテクチャはどの業務ドメインにも使えるというわけではない。しかし,だからこそ,アーキテクトは幅広い見識と経験,多くの引き出しが必要だ。銀の弾丸はなく,どのドメインにも最適な解はない。

なお,『リアルタイムOSから出発して 組込みソフトエンジニアを極める[改装版]』は,全編 仮想の電子レジスター 商品群をテーマに,今回書いているようなことを解説している。

今回の特集記事は,この本で書いたことを,実機で実現できると証明するために書いた。机上の空論と言われたくなかったからだ。

次回からは,実際にどのような構造にすると実現できるのかを説明していく。

大規模・複雑化している組込みソフトウェアにC言語だけで取り組んでいるエンジニアに,オブジェクト指向設計やC++などのオブジェクト指向言語を使うと,開発がこんなに楽になるよと伝えたいというのも,この特集記事を書いている理由だ。