すみません、初めてのコメントです。実は私、高校生なんですが、組込みソフトに興味を持っています。今、私たちの生活の中で( 身近なところ)よく使われている組込みソフトってなんですか。 答えてくれるならすごくうれしいです。お願いします。
そもそも、このブログを始めた最初の目的は読者との双方向コミュニケーションなので、いただいたお題に対して答えてきたいと思う。（＝○○）の記述は大人向けの解説。
自分は組込みソフトを説明するときにこの絵を使うことが多い。
まずは、一番左を見てもらいたい。
そもそも、人間が生活していく上であると便利なものはたくさんある。便利なものがあってもオーダーメードで作っていたのでは多くの人に使ってもらうことができない。
だから、加工しやすい部材を使って同じ働きをするものをいくつも作ることを人間は考えた。加工しやすい部材とは古くは木材であっただろう。今でも木はさまざまなものに加工され商品となっている。
その後、電気で動く部品（トランジスタなど）が発明され、定電圧で動くさまざまな電子部品、機械部品が作られて流通するようになった。これらの電子部品、機械部品の中にはセンサーと呼ばれる外界の状態をセンシングする電子部品や、モーターのように物理的に物体を動かすことのできるアクチュエータと呼ばれる機械部品もある。
これらセンサーやアクチュエータは、総称してハードウェアと呼ばれる。ハードウェアは決められた入力に対して決められた動作をする。それぞれのハードウェアにはデータシートもしくはスペックシートという取扱説明書がついている。ハードウェア部品を利用するエンジニアはこの取扱説明書を見てある目的を達成するための機器を作ろうとする。
センサーを使うと外界の状況を機器に取り込むことができる。また、アクチュエータにある入力を与えると何らかの動作をさせることができる。
センサーとアクチュエータを組み合わせると、外界の状況に合わせて組込み機器に何らかの動作をさせることができそうだ。ところが、センサーからの出力をアクチュエータに直接つないで期待通りの動きをさせることができるかというとなかなかそうはいかない。
センサーからの出力を期待通りの動きになるように変換してからアクチュエータに入力してしなければいけない。
このハードウェアとハードウェアの間に入って信号を変換する役割を担うのが元祖組込みソフトウェアだ。（上図の左）
組込みソフトウェアはCPU（中央演算装置：Central Processing Unit）という特殊なハードウェアにプログラムで命令を与えることで、信号をいろいろな信号に変換することができる。プログラムは書き換えることが可能なので、いろいろな信号の変換を試してみて「これでいける」と思ったら完成したプログラムをROM（Read Only Memory）と呼ばれる電子部品に書きこんで組込み機器に搭載する。（＝設計情報の転写）
ハードウェア部品群とハードウェアとハードウェアをつなぐソフトウェアが協力しあって組込み機器が完成する。ハードウェア部品もソフトウェアも同じものを大量に生産できるので工場で部品を組み上げて消費者に届けることができる。（＝設計から生産へ）
上図の左で、ハードウェアとハードウェアの隙間を埋めるような感じでソフトウェアを描いているのはソフトウェアにこんな特長があるからだ。
もうひとつ別な見方をすると、ユーザーや市場が欲しいと思うものに対して、メーカーは何らかのキーデバイスを選択して「こんな素晴らしいハードウェアを使った商品なんですよ」と宣伝する。
例えば薄型テレビのキーデバイスはもちろん液晶パネルやプラズマのパネルだ。このキーデバイスが表の顔であり、この表の顔にユーザーは惹かれる。（＝コアコンピタンスとしてのハードウェア）
しかし、大抵の場合キーデバイスだけでは組込み機器に目的の動作をさせることはできない。ユーザーやマーケットが欲している機能や性能を実現するためには、キーデバイスの能力を引き出すソフトウェアが必要になる。これが組込みソフトウェアだ。（＝コアコンピタンスとしてのソフトウェア）
ユーザーやマーケットの要求が複雑でかつ多様になるにつれ、組込み機器における組込みソフトの割合は大きくなってきた。
最初の絵の左から右への変遷がその様子を表している。今ではソフトウェアの分量は20年前の100倍から1000倍以上になっており、ハードウェアとハードウェアの隙間を埋めるためだけの役割だけではなくなってきている。
ソフトウェア自体を再利用可能な部品にしてそれらを組み合わせることもしないと、ソフトウェア作りが間に合わなくなってきた。（＝ソフトウェアプロダクトラインの必要性）
昔はハードウェアとハードウェアの間を埋めるだけの役割をソフトウェアが担っていたので、試作品に対して何らかの入力を与え出力をチェックしながらプログラムを直していって「これで完成」という時点でソフトウェアをフィックスすればよかったが、今ではそんなやり方をしていたらソフトウェアが固まるまで何年もかかってしまう。（＝Verification & Validationの計画と実行）
商品を作って他社との競争に勝つためには開発のスピード、商品が提供する機能や性能及び品質が大事になる。（＝マーケティングと要求品質定義、トレーサビリティ）
ハードウェアは故障することで製品の品質を悪化させるが、ハードウェア部品の故障を最小限にするための技術は長い年月をかけて確立してきたと言える。（＝故障解析、歩留まり）
一方でソフトウェアはバグと言われる意図しない動作をするプログラムが入ったまま製品を出荷することで製品の品質を悪化させる。これが市場で見つかるとメーカーは製品を回収してプログラムを正しいものに入れ替えたりする。（＝リコール）
ではバグをなくしてから製品を出荷すればよいのに・・・と思うだろう。それはそう簡単ではない。例えば、400字詰めの原稿用紙で100枚ぶんの作文を書いたとしよう。この4万字の作文の中で誤字脱字を一個もない状態にするにはどれくらいの時間がかかるだろうか。
100枚の原稿を何回も何回も見直したりしていると、ふとこ「この文章を直しておきたいなあ」と思うこともある。手書きの原稿ならいざ知らず、今はパソコンで簡単に直せるので余り気にせずに直してしまう。これを何回も何回も繰り返していると、いつの間にか直す前の文章と直した後の文章がどれがどれだか分からなくなりごちゃごちゃになってしまったりする。（＝構成管理、変更管理の必要性）
組込みソフトでもこれと同じことが起こる。100万行にも膨れあがったプログラムを一点のミスもない状態にするのは至難の業であり、時間もかかるし、みんなの知恵を借りていろいろなくふうをしないといけない。（＝ソフトウェア工学の利用）
最後に、ひとつ現代の組込みソフトエンジニアのやりがいというプラスの面を書いておこう。ハードウェアは決まった動きをする要素部品であり、ハードウェアエンジニアは目的を果たすためにどのハードウェアをどのように組み合わせればよいかを考え、その考えを製品で実現し大量生産できるようにする。（＝組み合わせとすり合わせの組み合わせ技術）
ソフトウェアエンジニアはハードウェアの構成が決まれば、勝負の世界は自分が書くプログラムにゆだねられる。毎日のプログラミングの積み重ねが商品の善し悪しを決定する。（＝組み合わせとすり合わせ技術のすり合わせ技術）
ある意味、自分の技術や努力の結果が商品の品質にストレートに影響するとも言える。ようするに腕のよいソフトウェアエンジニアが書いたプログラムが高い商品価値を生み出すということだ。技術的な成長を反映させやすい、また成果を実感しやすい仕事であるとも言えるだろう。
また、ハードウェアとソフトウェアが協力して合って組込み機器ができあがるため、特にアクチュエータが使われていると物理的な動きが見えてきて機器が完成して自分の思い通りに機器が動いたとき喜びが大きい。そして、自分が作ったソフトウェアが組込み機器に載って多くのお客さんに使ってもらえるという喜びもある。これらが組込みソフトの醍醐味である。（＝組込みソフトエンジニアのモチベーションの源泉）
以上、「組込みソフトってなに？」の疑問の解消にこの記事が少しでも役に立てれば幸いである。
自分は組込みソフトを説明するときにこの絵を使うことが多い。まずは、一番左を見てもらいたい。
そもそも、人間が生活していく上であると便利なものはたくさんある。便利なものがあってもオーダーメードで作っていたのでは多くの人に使ってもらうことができない。
だから、加工しやすい部材を使って同じ働きをするものをいくつも作ることを人間は考えた。加工しやすい部材とは古くは木材であっただろう。今でも木はさまざまなものに加工され商品となっている。
その後、電気で動く部品（トランジスタなど）が発明され、定電圧で動くさまざまな電子部品、機械部品が作られて流通するようになった。これらの電子部品、機械部品の中にはセンサーと呼ばれる外界の状態をセンシングする電子部品や、モーターのように物理的に物体を動かすことのできるアクチュエータと呼ばれる機械部品もある。
これらセンサーやアクチュエータは、総称してハードウェアと呼ばれる。ハードウェアは決められた入力に対して決められた動作をする。それぞれのハードウェアにはデータシートもしくはスペックシートという取扱説明書がついている。ハードウェア部品を利用するエンジニアはこの取扱説明書を見てある目的を達成するための機器を作ろうとする。
センサーを使うと外界の状況を機器に取り込むことができる。また、アクチュエータにある入力を与えると何らかの動作をさせることができる。
センサーとアクチュエータを組み合わせると、外界の状況に合わせて組込み機器に何らかの動作をさせることができそうだ。ところが、センサーからの出力をアクチュエータに直接つないで期待通りの動きをさせることができるかというとなかなかそうはいかない。
センサーからの出力を期待通りの動きになるように変換してからアクチュエータに入力してしなければいけない。
このハードウェアとハードウェアの間に入って信号を変換する役割を担うのが元祖組込みソフトウェアだ。（上図の左）
組込みソフトウェアはCPU（中央演算装置：Central Processing Unit）という特殊なハードウェアにプログラムで命令を与えることで、信号をいろいろな信号に変換することができる。プログラムは書き換えることが可能なので、いろいろな信号の変換を試してみて「これでいける」と思ったら完成したプログラムをROM（Read Only Memory）と呼ばれる電子部品に書きこんで組込み機器に搭載する。（＝設計情報の転写）
ハードウェア部品群とハードウェアとハードウェアをつなぐソフトウェアが協力しあって組込み機器が完成する。ハードウェア部品もソフトウェアも同じものを大量に生産できるので工場で部品を組み上げて消費者に届けることができる。（＝設計から生産へ）
上図の左で、ハードウェアとハードウェアの隙間を埋めるような感じでソフトウェアを描いているのはソフトウェアにこんな特長があるからだ。
もうひとつ別な見方をすると、ユーザーや市場が欲しいと思うものに対して、メーカーは何らかのキーデバイスを選択して「こんな素晴らしいハードウェアを使った商品なんですよ」と宣伝する。例えば薄型テレビのキーデバイスはもちろん液晶パネルやプラズマのパネルだ。このキーデバイスが表の顔であり、この表の顔にユーザーは惹かれる。（＝コアコンピタンスとしてのハードウェア）
しかし、大抵の場合キーデバイスだけでは組込み機器に目的の動作をさせることはできない。ユーザーやマーケットが欲している機能や性能を実現するためには、キーデバイスの能力を引き出すソフトウェアが必要になる。これが組込みソフトウェアだ。（＝コアコンピタンスとしてのソフトウェア）
ユーザーやマーケットの要求が複雑でかつ多様になるにつれ、組込み機器における組込みソフトの割合は大きくなってきた。
最初の絵の左から右への変遷がその様子を表している。今ではソフトウェアの分量は20年前の100倍から1000倍以上になっており、ハードウェアとハードウェアの隙間を埋めるためだけの役割だけではなくなってきている。
ソフトウェア自体を再利用可能な部品にしてそれらを組み合わせることもしないと、ソフトウェア作りが間に合わなくなってきた。（＝ソフトウェアプロダクトラインの必要性）
昔はハードウェアとハードウェアの間を埋めるだけの役割をソフトウェアが担っていたので、試作品に対して何らかの入力を与え出力をチェックしながらプログラムを直していって「これで完成」という時点でソフトウェアをフィックスすればよかったが、今ではそんなやり方をしていたらソフトウェアが固まるまで何年もかかってしまう。（＝Verification & Validationの計画と実行）
商品を作って他社との競争に勝つためには開発のスピード、商品が提供する機能や性能及び品質が大事になる。（＝マーケティングと要求品質定義、トレーサビリティ）
ハードウェアは故障することで製品の品質を悪化させるが、ハードウェア部品の故障を最小限にするための技術は長い年月をかけて確立してきたと言える。（＝故障解析、歩留まり）
一方でソフトウェアはバグと言われる意図しない動作をするプログラムが入ったまま製品を出荷することで製品の品質を悪化させる。これが市場で見つかるとメーカーは製品を回収してプログラムを正しいものに入れ替えたりする。（＝リコール）
ではバグをなくしてから製品を出荷すればよいのに・・・と思うだろう。それはそう簡単ではない。例えば、400字詰めの原稿用紙で100枚ぶんの作文を書いたとしよう。この4万字の作文の中で誤字脱字を一個もない状態にするにはどれくらいの時間がかかるだろうか。
100枚の原稿を何回も何回も見直したりしていると、ふとこ「この文章を直しておきたいなあ」と思うこともある。手書きの原稿ならいざ知らず、今はパソコンで簡単に直せるので余り気にせずに直してしまう。これを何回も何回も繰り返していると、いつの間にか直す前の文章と直した後の文章がどれがどれだか分からなくなりごちゃごちゃになってしまったりする。（＝構成管理、変更管理の必要性）
組込みソフトでもこれと同じことが起こる。100万行にも膨れあがったプログラムを一点のミスもない状態にするのは至難の業であり、時間もかかるし、みんなの知恵を借りていろいろなくふうをしないといけない。（＝ソフトウェア工学の利用）
最後に、ひとつ現代の組込みソフトエンジニアのやりがいというプラスの面を書いておこう。ハードウェアは決まった動きをする要素部品であり、ハードウェアエンジニアは目的を果たすためにどのハードウェアをどのように組み合わせればよいかを考え、その考えを製品で実現し大量生産できるようにする。（＝組み合わせとすり合わせの組み合わせ技術）
ソフトウェアエンジニアはハードウェアの構成が決まれば、勝負の世界は自分が書くプログラムにゆだねられる。毎日のプログラミングの積み重ねが商品の善し悪しを決定する。（＝組み合わせとすり合わせ技術のすり合わせ技術）
ある意味、自分の技術や努力の結果が商品の品質にストレートに影響するとも言える。ようするに腕のよいソフトウェアエンジニアが書いたプログラムが高い商品価値を生み出すということだ。技術的な成長を反映させやすい、また成果を実感しやすい仕事であるとも言えるだろう。
また、ハードウェアとソフトウェアが協力して合って組込み機器ができあがるため、特にアクチュエータが使われていると物理的な動きが見えてきて機器が完成して自分の思い通りに機器が動いたとき喜びが大きい。そして、自分が作ったソフトウェアが組込み機器に載って多くのお客さんに使ってもらえるという喜びもある。これらが組込みソフトの醍醐味である。（＝組込みソフトエンジニアのモチベーションの源泉）
以上、「組込みソフトってなに？」の疑問の解消にこの記事が少しでも役に立てれば幸いである。
先日、コメントを書かせて頂きました『自動車エンジニア』です。
また、コメントさせて頂きます。
-----------------------------------
プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。
----------------------------------
確かにそのとおりだと思います。
自動車業界でいうと、モデルベース開発がMATLABという１つのツールに依存しすぎると、ツールベンダーに主導権を握られるリスク当然はあります。
実際そうなりつつありますが...
MathWorksがマイクロソフト状態にならないように、MAAB、J-MAABなんかでも、MathWorksにソフト改良への要求などを（強気に?）行って、かなり牽制しようとしてますが...
デンソーなんかは、ツールベンダーに依存しなくてよいような方向を志向しているのかどうかわかりませんが、最近はプラットフォーム環境を内製化しようとしてしいる感じは、各公演等から感じられます。
トヨタでも同じようなことは考えられているかもしれません。
----------------------------------
重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。
----------------------------------
参考までに、トヨタは自前で組み込み用のＯＳの開発を行っているようです
あくまで、メディアの情報です。
【トヨタ、「クルマＯＳ」独自開発】
【50人体制の開発組織・トヨタ正発表】
【経済産業省、車載標準OSを開発へ--トヨタや日産らが参加】
トヨタも現状は、サプライヤーにソフトの供給を依存しているかもしれませんが、もしかしたら、将来的に自前でいくことも考えているのかしれませんね。
ただ、本当の戦略？？です
-----------------------------------
これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。
----------------------------------
自動車業界にいる者として、真摯にご指摘を受け止めなければなならないと思います。
現状、車メーカー側には組み込みのエキスパートは少ないように感じます。
いくつかの車メーカーはグループ内にＥＣＵメーカーをもっていて、組み込みは子会社のＥＣＵメーカーに任せて、車メーカーはシステムのアルゴリズム開発に注力するという方向かもしれませんが、それが、大問題の原因になるとのご指摘かと思います。
車メーカー：組み込みの素人、制御アルゴリズムや車両の特性には詳しく、ロジック開発のみやる
⇒どんどん、組み込みに疎くなる。
⇒【組み込み技術】と【制御ロジック/制御対象特性】の両方を把握するエンジニアがいなくなる。
システム/組み込み開発で全体を把握でる人がいなくなり、部分分のみの知識/経験しかない人だけになると絶望的になる。
さらに、自動車の特性に関する知識に疎いツールベンダーが、人命を預かって走る車において、ＥＣＵの組み込みの根幹を握るようにると、さらに怖いというご指摘かと思います。
（間違っていたらご容赦ください）
車メーカー側は組み込み技術の向上（組み込みエンジニアの育成も含めて）を真剣に考えていかなければいけなかと思います。
最後は車メーカーが全ての責任をとらなければいけませんので、組み込みＥＣＵの責任も最後は車メーカーが持たなければなりません。
私も、組み込みに関する知識不足を痛感しています。
最近、組み込み関連の本を何冊か購入して勉強していますが...
『組込みソフトエンジニアを極める』も今、読ませて頂いております！
ＥＣＵメーカーの組み込みエンジニアとも情報交換及び、今後のシステム/組み込み開発のやり方を議論する場なども定期的にもっていたりします。
----------------------------------
こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。
----------------------------------
私もそんな１人ですね（笑）
ベンダーの営業トーク（いいことしか言わない）によくコロッといったりします（笑）
9月 08, 2007
自動車エンジニアさん、コメントありがとうございます。
自動車エンジニアさんは本当に自動車のソフトウェア開発にお詳しいですね。
自動車のソフトウェア安全については、ISO 26262 の策定が進んでいると思いますが、ソフトウェアの安全性を分析する考え方として MISRA-SA というのもあります。
どっちにしても、ソフトウェアの安全性は電気的安全性のようにはっきりと白黒つけることは難しいので、エンジニアがどれだけ客観的な根拠・証拠をもってシステムの安全性や信頼性を証明できるかどうかにかかっていると思います。
自動車ソフトウェアの安全性は、これまでソフトウェアエンジニアがユーザーの要求や機器のメカニズムを熟知しており、どんな風に使われるのか、どんな風に ハードソフトが動くのか知っていてソフトウェアを作っているということで担保されていた部分が大きかったと思いますが、これからは誰がどんなソフトウェア を作り込んでしまうか分からないという前提で、ソフトウェアの安全性や信頼性が確保されていることを客観的に示していかないといけないと思います。
モデルベース開発は安全を客観的に示すための有力な方策の一つだと思いますが、モデル変換のソフトウェアを作っているエンジニアが特に車のメカニズムを意識していない場合、意図しない洩れや抜けにより変なコードが埋め込まれてしまう可能性はあると思います。
ただ、「理系白書から考えるソフトウェア工学」で書いたように、モデルベース開発が自然科学を相手にしているうちは正しく変換できているという信頼性をVerification（検証）することは難しくないと思います。
しかし、自然科学以外のすり合わせ的ソフトウェアアーキテクチャをモデル駆動開発に取り込んでいった場合は、信頼性の証明やシステム全体のValidation（妥当性確認）は難しくなってくると予想します。
組織内部の Closed のすり合わせ的アーキテクチャ・アルゴリズムの安全性や信頼性は、そのハード・ソフトが使われる場面や要求を実現するメカニズムを熟知しているソフトウェ アエンジニアの「慎重さ」「そのソフトウェアが安全を担っているという使命感」のようなものが確保していたのが本当のところでしょう。（要求通りに作られ ているかどうかを検証するのは Verification です）
これからは、その安全アーキテクチャ、安全ソフトウェアをカプセル化して、他の安全クラスの低いソフトウェアから隔離し、影響を受けにくいソフトウェアの構造を作っていかないといけないと思います。
これは ECUが物理的に分かれていることで責任分担され証明しやすかった状態に比べると、自信を持って「安全です」と言えるところまで持っていくのに時間も手間やソフトウェア的工夫もいるだろうと予想しています。
自分は自動車ドメインのエンジニアではありませんが、このブログでもその方策について考えていきたいと思います。
9月 08, 2007