2019日2月20日に東京代々木の国立オリンピック記念青少年総合センターにて,「医療機器ソフトウェアの最新技術動向セミナー」を開催します。募集定員は300名です。ヘルスケアドメインに新規参入を検討している企業や,クリティカルソフトウェアのリスベースアプローチの実際について知りたい方に参考になると思います。医療機器業界では,現在「リスクマネジメント」「ユーザビリティ(使いやすさというよりは,有効性を高め,危険状態になりにくい機器の使い方)」「サイバーセキュリティリスクマネジメント」などについて規制要求があり,本セミナーでそれらの最新情報をゲットできるような内容となっています。ヘルスアプリや遠隔医療,介護ロボットなど,さまざまな新サービスが世の中に出てきていますが,その延長線上には規制対象の医療機器になるかもしれないという未来があると思います。なる前に,現状で医療機器ソフトウェアにどんな要求が求められているのかを知っておくことは重要です。ヘルスケアインダストリ部会のページより転載します。3-1)医療機器ソフトウェアを取り巻く環境は、急速に変化しつつあります。日本においても平成26年11月に医薬品医療機器法が施行され、医療機器ソフトウェアが「プログラム」として法規制の対象になり、平成29年11月24日まで経過措置となっていた最新の技術に基づく開発ライフサイクルの適用が始まりました。当セミナーでは、まず医療機器ソフトウェアに関連のある規格の最新動向を解説します。これは毎回のセミナーで行っているもので、毎年の変化、動向をいち早く掴めるようにしています。80001シリーズ、さらに現在策定中の規格についても説明を行います。14971の理解、考え方、そして実践に向けての対応について説明を行います。サイバーセキュリティ関連については、2015年4月厚生労働省より「医療機器におけるサイバーセキュリティの確保について」、続いて2018年7月には、「医療機器のサイバーセキュリティの確保に関するガイダンス」は発出されました。Devices」のドラフトガイダンスが公開されました。近年より重要度が増している内容であり、当セミナーでもより時間をあて、説明を行います。62366-1の理解と考え方と題して、説明を行います。規格・ガイダンスは毎日のように公開、発出されており、これらを網羅することもなかなかできません。今まで当セミナーで取り上げたことない初めての試みとなりますが、「規格・ガイダンスとの上手なつきあいかた」と題して、我々が意識すべきことを説明させていただきます。業務に従事される方はもちろんのこと、医療情報ベンダー、医療機器分野に新規参入する方々にも有益なセミナーになると考えております。皆様のご参加をお待ちしております。都合により、プログラム・講師が変更になる場合もございます。※先着順とし定員に達し次第、締切りとさせていただきます。下記の「受講申込フォーム」に必要事項をご記入の上、送信してください。(受付システムについては(株)ビズクリエイトのサービスを使用しているため、JEITA外部のサーバに移動します。お申込み内容の確認後、折り返し「参加申込完了メール」が送信されます。メールをプリントアウトし、セミナー当日に会場受付へご提出ください。(お持ちでない場合は、名刺を1枚頂戴いたします。受講料の「請求書」は郵送にてお申込者様宛にお送りいたします。金額・内容をご確認の上、ご入金をお願いいたします。受講料の振込手数料はお申込者様各位にてご負担願います。当日、現金の取り扱いは行いませんので、ご了承下さい。ご登録後のキャンセル、参加費の払い戻しはお受けできませんので予めご了承ください。お申込者様が参加できない場合は、是非、代理の方のご参加をお願いいたします。お申込みの締め切りは2019年2月18日(水)です。この投稿へのリンク2018-12-02個別最適の時代は完全に終わった(ソフトウェア品質のパラダイムシフトについて考える)サイバーセキュリティのことにクビを突っ込んでいると,ソフトウェア品質の概念が根底から変わったのではないかと感じる。利用可能な商用ソフトウェア)やオープンソースのソフトウェアを使うのは当たり前になっている。組込みソフトウェアであっても何十万行にもなるソフトウェアにOTSを使わないケースはほとんどない。OTSには長い間使っているとサイバーセキュリティ上の脆弱性が見つかる。ここでよく考えた欲しいのはセキュリティの脆弱性は,ソフトウェアのバグ(欠陥)なのかという点だ。出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。作り込みを防止し、検証や妥当正確認によって発見・除去する。定義となるが,脆弱性はソフトウェアに起因する問題ではあるがユーザーオペレーションが原因で発生するわけではない。出荷前の検査で発見することは難しく,出荷後に発生してから分かることが多いというのはそのとおりだが,検証や妥当性確認によって発見,除去できないものもある。脆弱性は悪意を持ったハッカーが意図的にソフトウェアの穴を見つけて,そこを攻撃し,その悪用が成功すると,そこが脆弱性になるからだ。ようするに,仕様通りに作った設計通りのソフトウェアであっても,悪意をもったハッカーにより「正しく作ったソフトウェア」でも「脆弱性」にされてしまうことがあるということだ。設計通りに作ったソフトウェアでも後々「脆弱性=欠陥」となってしまうのって,ソフトウェア品質を考える上でのパラダイムシフトではないかと思うのだ。どんなに頑張って信頼性を高めようとしても,ソフトウェアに穴を見つけようとするハッカーがいるかぎり「脆弱性=欠陥」は発生してしまう。これはソフトウェアに完成というゴールは存在しないということを意味する。組込み機器がIoTの流れに乗って,ネットワークにつながるようになると,ネットワーク越しに脆弱性を攻撃される危険にさらされる。世界の中にいる一流のハッカーやあるいは,各国の軍事組織が意図的に作成したマルウェアは,コピーできたり自分自身が増殖したりできるので,IoT機器がインターネットに接続されていれば,そのソフトウェアが市場に存在し続ける限り,脆弱性=欠陥が発生するリスクがある。リスクが発生する確率は確率論で測ることはできない。ハッカーが攻撃したいと思うかどうかだ。ハッカーがその製品の企業に気にくわない対応をされたのかもしれない。有名な企業やセキュリティがが高いとされている企業の鼻っぱしを折ってやろうという気になったのかもしれない。セキュリティインシデントを発生させて,わざと株価を低下させようと企んだのかもしれない。ようするに,悪用の可能性(Exploitability)は従来の確率(Probability)や起こりやすさ(Likelihood)の概念では測りきれないのだ。Materials)のリストを提供することを求めている。サイバーセキュリティの脆弱性を監視する必要があるソフトウェアやハードウェアを搭載しているならば,それをリストにして提出せよと言っている。DATABASE)と相互参照することを求めている。NDBは過去の脆弱性の報告があったソフトウェアやハードウェアが全てデータベース化されている。そこに載っているハードウェアやソフトウェアを使っているならば,それをリストにして提出しなさいと言っている。市販後の新たな脆弱性が見つかったら,脆弱性を含むOTSを搭載する該当製品に対してパッチを当てるように勧告するのだろう。ようするに,IoT機器のソフトウェアは,クリティカルなソフトウェアに限らず市販前に完成度の高いソフトウェアを作ってリリースしたら終わりにはならないのだ。これまでも,仕様変更やバグが見つかったら,ソフトウェアの改変を行っていたかもしれないが,仮に市販前に仕様通り作った完璧と思ってリリースしたソフトウェアであっても,製品が市場にある限りサイバーセキュリティの対応が終わらないということになってきた。サイバーセキュリティは商品の価値としては潜在的な価値に分類される。潜在的な価値は,カタログスペックには出てこないが,セキュリティインシデントが発生することで,その潜在的価値がクローズアップされる。サイバーセキュリティの堅牢性は当たり前品質であるとも言える。ユーザーにとってはできていて当たり前だが,普通に使ってるぶんにはその価値は見えてこない。セキュリティインシデントが発生したときにはじめて,その価値の重要性に気が付く。製造業者側としては,事前に仕込んでおかないといけない価値となる。メーカーとしては,そこにコストをかけたくないところだが,セキュリティインデントが発生すると,著しく企業価値が下がり,ダメージが大きいので対処しない訳にはいかない。難しいのは,セキュリティ対策には終わりがないので,どこまでやればいいかの線引きが非常に難しいのだ。市販前の考え方としては,クリティカルな製品においては,セキュリティインシデントが発生したときのユーザーのリスクが許容できるかどうかで判断し,また,過去に発生したセキュリティインシデントが再発しないような対策を積み重ねていく。その対応をしたからといって,製品をリリースして終わりではないという認識を持ってセキュリティに対応する。ユーザーにとってIoT時代はいろいろと便利なサービスが提供されるという点ではいいのだが,メーカーはその裏でサイバーセキュリティ対策をしないといけない。最終的にはそのコストはユーザーが負うことになる。ユーザーは便利の裏側でセキュリティのコストを払うことになるのだ。どこまでコストをかければいいのかはメーカーが判断しなければいけない。日々コストと戦っている製造業者には頭の痛い問題だ。ソフトウェアのバグの発見とはまた別の意味で,悪用の確率を予測しにくい「やから」が相手ときている。ソフトウェア品質の話に戻ろう。これまでソフトウェアの品質の議論は,主にリリース前までにいかにバグを潰すかという論点で進んで来たが,今後は市販後も含めたソフトウェアのライフサイクル全体を考えなければいけなくなってきた。悪意を持ったハッカーはどんなに完成度が高いソフトウェアであっても(わざわざ,堅牢なソフトウェアの穴を見つけようとはしないだろうが)穴を見つけ出そうとする。そこには悪意があるから防ぎようがない。オープンソースのソフトウェアは便利だからみんな使っているが,脆弱性との戦いは一生終わらないと思った方がいいだろう。ソースコードをオープンにして脆弱性を見つけてくださいと言っているのと同じだからしょうがない。ハッカーがその気になるかならないかは,ハッカーの気分次第なのだ。ちなみに,悪意を持ったハッカーではない,善意のハッカーと称する者は,わざわざソフトウェアの穴となりうる脆弱性を見つけてセキュリティインシデントを発生させてみて「この商品は危ないですよ」とデモンストレーションして,多くの人の注目を浴びたいため?に脆弱性をわざわざ指摘してくれる。(脆弱性を見つけた時点で公表する前にOTSの製造業者にお知らせしてくれるが,製造業者としては脆弱性を見つけてくれない方がうれしいと思うのは自分だけだろうか?)自動車業界はサイバーセキュリティを多層防御で乗りきろうとしているかもしれない。本当にそれで乗りきれるだろうか。車載ソフトウェアでもどこかでOTSやオーブンソースのソフトウェアは使われているだろう。ナビゲーションシステムやAIのソフトウェアだって使うかもしれない。ナビゲーションシステムは自動車の制御ソフトウェアとつながるようになるかも知れない。ナビゲーションシステムのソフトウェアに脆弱性が見つかってしまったらどうするのだろうか。脆弱性があっても多層防御しているから大丈夫ですと言い切るのだろうか。ソフトウェアの場合,弱いところがあることが分かってしまうと,どんなに発生確率が低いと説明しても「直せるのなら直せ」と言われ,直さざるを得ない宿命がある。脆弱性が見つかったら,パッチを当てるしかないのだ。そのためには,ソフトウェアを安全にアップデートするしくみが必要になり,アップデートすることを前提にしてソフトウェアをリリースすることになる。このことは,「ソフトウェア製品はリリース時に完成しない」時代になったということではないか。リリース時にバグはないかもしれないが,潜在的な脆弱性や未来に脆弱性となってしまうソフトウェアが含まれている状態で出荷せざるを得ないのだ。このサイバーセキュリティを起因としたパラダイムシフトは,企業のソフトウェア開発の体制にも影響を与える。Team)が必要になる。ソフトウェア品質はソフトウェア部品の信頼性を高めて,それを組み上げるといったアプローチの有効性が低下し,個別最適から全体最適の時代に完全に切り替わったのだと思う。ようするに,製品のリリース時点では,サイバーセキュリティの脆弱性は発生するという前提で市販後の対応をする必要があり,商品のリリース時には,対ユーザーリスクをなくすことはできないので,できるだけ小さくすることを考えることが必要になったのである。これはソフトウェアのテストについても同じことが言える。仕様通りに作っても脆弱性となってしまうケースがある以上,テストがソフトウェアの完成度を確認する手段なら,製品リリース時に完全なテストは実施できないことになる。ソフトウェアは一生完成しないという前提に立てば,完全なテストも存在しないと言えないか。完全なテストを行うことを目指すのではなく,ユーザーリスクが最小になるようなテスト,検証,バリデーションを設計しないといけない。ソフトウェア開発のおいて,また,ソフトウェア品質向上施策において,ソフトウェア部品の信頼性やセキュリティを個別に高めて結合すれば,システムも安全で,高品質でセキュアであるという時代ではなくなった。ユーザーに対して商品に責任を持つ組織が,全体最適として商品の安全性や信頼性やセキュリティのリスクを最小限にする方策を考え実施し,そして商品が市場にある限り,ライフサイクル全体でOTSの脆弱性対応を含めたサービスを提供することが必要になってきた。工場で製品作って出荷することが製造業者のゴールではなくなったということだ。そのサービスのコストが最終的には便利と引き換えにエンドユーザーが負うことになる。(Atom)組込みソフトウェア工房へようこそ本ブログサイトでは技術を磨き、組織を通じて顧客満足度を高めたいと考えるエンジニアを応援します。*注目の投稿ソフトウェアアーキテクチャとは何かを考える最近,協力会社に開発を任せていてソフトウェアの中身が分からず,意図した動きにならない(レスポンスが遅いとか,画面が思ったように遷移しないとか)という話を聞いた。,「ソフトウェアを継ぎ足し続けた結果,肥大化・複雑化して,原因を追及しにくい不具合が発生して困っている。「最初に読んで欲しいこと。英和対訳版が手元に届いた。こだわっている理由を書こうと思う。自分は医療機器ドメインのソフトウェアエンジニアとしてのキャリアが24年である。特集記事『クルマの電子安全始まる-ISO26262を越えて-』を必ず読んでほしい。26262の世の中の動きをウォッチしていくこと自体にいささか疲れてきた。言って、本当にユーザーのことを考えて安全や安心を実現したいのなら、自動車業界の規格適合に関する浮かれた熱が冷めるのを2~3年待った方がよいと考えるようになってきた。機能安全に群がる商魂...安全を売りにするな!安全を食いものにするな!最近、どうしてもペンを取りたいと思わせることが二つ起こった。ひとつは、マツダの安全装備の体感試乗会で起きた「CX-5」の事故で、もうひとつは2007年に起こったトヨタの急加速事故に関するトンデモ検証記事だ。』(渡辺健介著)という本を読んだ。いつものように、まえがきを紹介したいと思う。壁に直面したとき、自分の...レクサスのパワーステアリング不具合の原因分析についてトヨタ自動車は19日、ハンドルが一時的にタイヤと連動しなくなる不具合があるとして、レクサス4車種のリコールを決めた。今回もプリウスのときと同様にソフトウェアの複雑性が絡んだ問題のようだ。リスク分析、リスクアセスメントについての話題である。イントロダクションを読む自分は組織内で次の(2)の立ち位置にいる。プリウスのブレーキ制御問題について、これまでになく詳細な情報が掲載されており、問題がなぜ起こったのかを推察できるからだ。日経もの...自己紹介sakai1987年よりクリティカルデバイスのソフトウェア開発に従事する。16bitのワンチップマイコンを使った信号処理、リアルタイム組込みシステムの開発を行い、商品の仕様立案からソフトウェア開発のプロセス管理、プロジェクトマネージメント、安全性・信頼性の検証、保守、ソフトウェア技術者教育など組込みシステム開発に関する幅広い領域を経験する。オブジェクト指向設計やプロダクトライン戦略を商品開発に生かすことも試みる。商品開発を常にアーキテクトの視点から分析し、「具体から抽象へ」というアプローチにこだわる。)に、2011年より組込みソフトウェアギルドに参加している。