富士機工株式会社様

開発に携わるドメインと業務内容について

• 最初に自己紹介を兼ねて、入社から現在までの関わってきた業務について、お話し頂きました。
  
  – 現在、どの様な製品の開発に携わっておられるか、自己紹介を含めて教えてください。

• 飯田様：
  弊社、富士機工は、シフターと呼ばれる自動車のシフト操作に関わる製品を開発しています。私は、パワートレイン設計部第二設計室の室長をやっております。富士機工に入って21年になります。入社以来長い間、メカ設計を行っていました。トランスミッションに付くドライブプレートや、エンジンの補機を回すプーリーなど、エンジン部分の鉄部品の設計です。
  
  
• 

• 電子制御の分野については、現在の電子制御を伴うシフターに携わるまでは、どこかの部署で電気部品も開発しているんだなという話を聞く程度でした。会社の動きや組織変更が色々とありまして、最近になって、電装部品が今後主力になって行くということで、パワートレイン設計部、第二設計室の室長を拝命しました。
  
  シフターは、人が触ってメカ的な操作をしますので、人の動きに対しての反応性などメカ的な要素が重要です。動く機構部品は当然入っていますが、これが電子制御されますので、その両方を融合させると言った意味で、現在のポジションに任命されたと思っています。
  
  自動車のシフト操作は、ドライバビリティ、日本語で言うところの「官能性」に関わります。開発したシフターの最終段階では、官能評価、応答評価の部分で、クライアントの要求に合わせた味付け、チューニングがありますので、ここを認めて頂けるようにするのが、非常に苦労するところです。

• 大西様：
  私は、富士機工に入社して7年目になりますが、実は前職では自動車以外の業種、家電製品から半導体の製造プロセスなどを経験してきたというバックグラウンドを持っています。後に、富士機工に関連する業務を何年かしていましたが、これをきっかけに、当社へ入社することになりました。
• 

• 現在は、電子技術グループに所属しており、制御システムの設計をしております。弊社の製品は、元々は機械製品だったのですが、10年ほど前から自動車の電動化の波に晒されて、対応しなければばらないという課題が上がり、この部署が立ち上がりました。その中で、自動車の安全設計の業界全体での導入が進み、弊社も機能安全への対応に迫られることとなり、苦慮しながら進めている所です。
  
  その中で、私はシステム設計を担当しています。機能安全規格ISO 26262のパート４に当たる部分です。ハードウエアとソフトウエアの両方に関わる制御システムのアーキテクチャの設計を担当しています。

開発製品「シフター」について

• – 開発されているシフターについて、教えていただけませんか？

• 大西様：
  シフターとは、自動車のオートマのシフトレバーの部分のことです。ひと昔前は、すべてが機械式でトランスミッションとつながっていました。ワイヤーやロッドが直接トランスミッションのギアにつながっていまして、そのギアを押したり引いたりすることで、トランスミッションを操作する構造でした。そのため、シフターは、それ単体では機能しない部品であり、トランスミッションとつながって初めて機能する部品でした。
  
  そのため、シフターのスペック決めや設計は単体で行うことはできず、トランスミッションにつながった時のスペックを想定して、シスターのスペック決めを行う必要があります。
  
  シフターは現在では完全に電子化されていますが、車両のインターフェース部品ですので、操作の感触や、見た目の質感が重要であることは、機械式の頃から変わりません。ただし、電子化された後では、バイワイヤーでつながっており、トランスミッションのメカとは切り離されていますので、これまでトランスミッションとセットで実現していたシフトした時の感触や操作力といったフィーリングを、シフター単体で満足しなければなりません。見かけ上のスペックは変わっていないのですが、中身や実現方法は全く違うものになっています。

シフターの操作感と、仮想環境・モデルを利用した設計

• – シフターの制御仕様を決めるにあたり、仮想環境やモデルを使用しているのですか？

• 飯田様：
  シフターのスペックには、ノブの感触やレバーの硬さ柔らかさ等があるのですが、操作したときにドライバーが思った力で思ったポジションに入ることや、変速時の反応の速さが得られることなどが重要です。これらが複雑に組み合わさって、最終的なフィーリングが決まると思います。
  
  バイワイヤーでトランスミッションと接続され、電子化された制御の場合、まず弊社内でシフター単体の実験や評価を行いますが、最終的には接続されるトランスミッションメーカーと共同で、変速操作のチューニングを行います。
  
  トランスミッションとの接続チューニングを行う前には、仮想環境での実験や評価も行っています。従来の実績データやノウハウの蓄積がありますので、実機で合うように十分に仮想上で合わせ込みを行ってから、最終的な実機でのチューニングへ臨んでいます。
• 

シフト制御のモデル化の取り組み

• – シフト制御の仕様を書くにあたって、どの様な取り組みをされてきたか教えていただけませんか？

• 大西様：
  国内のバイワイヤーの製品やシフターは、未だ制御の要素を持っておらず、操作の検出だけをするような製品が多かったのですが、制御を含めて、シフターの中で制御をクローズしてほしいという要求が上がってきました。そこで、シフト制御を自分たちの中で整理するためにどうしようかと考えていたのですが、当初は私1人で行っていました。ですが、全てを1人で作り上げることができる訳ではありませんので、その仕様を誰か他の技術者に伝える必要がありました。
  
  制御を含めたシフト操作を設計するにあたり、センサーの部分だとか検出対象だとかを少しずつモデル化して検討しようということになり、３Dモデルや計算上のモデルへの取り組みを始めました。自動車メーカーから提示される要求仕様は自然言語で示されることが多く、そのままでは制御設計の仕様にはなりません。このため、仕様を弊社の協力会社や他部署に出すに当たって、一度交通整理をする意味もあり、ブロック図で制御を表現し、仕様を伝えることから始めました。
  
  この中で、機能安全の話が出て来る様になったのですが、この機能安全設計の仕様をどの様に書き表せばよいのかが、１つの課題になってきました。最初はブロック図で、試行錯誤しながら書き表していました。ISO 26262の規格が自分たちには難解で、苦労していました。

SysMLによるシステム仕様の記述について

• – システムの制御仕様は「SysML」を使って記述されているそうですが、どのように行われているか教えていただけませんか？

• 大西様：
  制御の設計では、ステートマシン図は必要であれば書き起こすこともありますが、基本的には「SysML」を使って仕様を作っています。全く知識のなかったころは、「UMLと言うのがあるらしい」と、うわさ程度に聞いていたくらいでした。文献を調べてみると、UMLはソフトウエアの挙動を書くには向いていると思いましたが、システム仕様の粒度で仕様を書くには、ちょっと違うと思い、SysMLを使うようになりました。
  
  SysMLは、元々、メカ屋さんやエレキ屋さん、ソフト屋さんとの意思疎通を図るために使われることが多く、弊社の中でも、これを使って仕様のやり取りを行うようになっています。ブロック図、アクティビティ図、パラメトリック図、要求図など、その他もろもろの図を作っています。
  
  システム図をSysMLで書き、これを基に、ソフト屋さんメカ屋さんに仕様を示しています。状態遷移図も付けていますが、ソフト屋さんは、状態遷移図をそのままソフトウエアの仕様に取り込んでいるようです。

機能安全ISO 26262への取り組み

• – 御社のQMSや開発プロセスに対する機能安全ISO 26262への対応の取り組みについて、教えていただけませんか？

• 飯田様：
  今まで機能安全への対応を行う機会はありましたが、これを行うには会社を動かすくらいのリソースやパワーが必要で、どうしても案件の受注が必要でした。なかなか部品開発の受注を得ることができず、もどかしい思いをしましたが、昨年、案件の受注が決まり、本格的に進められる様になりました。
  
  ISO 26262への対応については、SPICEの資料を見ながらどうすべきかを１つ１つ重ねていくような作業を行っています。私の室（パワートレイン設計部、第二設計室）のチームをこれに合わせて再編成し、2018年度中には、今回受注した製品が安心して使って頂けるプロセスであることを証明できるようになることを目標に進めています。来年度には、これをさらに進めて、自己認証が行えるところまで進める計画をしています。
• 

安全コンセプト設計、SCDLについて

• – 「SCDL」を使った安全コンセプト設計を行う様になったきっかけと、その方法について教えていただけませんか？

• 大西様：
  ガイオさんのツールを紹介頂く機会があったのですが、この時に、機能安全の話題となり、アドバイザリーを行っているDNV GL ビジネス・アシュアランス・ジャパン株式会社(以下DNV GL)さんを紹介頂きました。DNV GLさんには「安全分析」や、機能安全の全体像を解説頂きました。
  
  最終的には機能安全に対応したプロセスを作ることが必要なのですが、まずは、設計に必要な安全分析の手法を習得することが先だと判断しました。ISO 26262のPart4がこの部分に相当しますが、安全分析についての詳細は規格化されておらず、「セミフォーマルで書くこと」程度の規定しか書かれていません。実際にどうやって実施するのかが分からず、DNV GLさんからアドバイザリーを受けた次第です。
  
  機能安全の仕様についても、最初はSysMLで書いてみようとしましたが、しっくり来ない結果となり、うまく表現できませんでした。アドバイザリーの中で「SCDL」を提案頂き、その手法で機能安全仕様を書いてみることにしました。当時は専用のツールがありませんでしたので、エクエルで書いていました。エクセルの中に図を作りながら、機能安全要求のつながりを記述していましたが、エクセルはただの絵ですので、一部修正すると、これに関連する部分をすべて手作業で修正することになります。これが大変な作業となり、苦労しました。
  
  しばらくして、機能安全設計の専用ツールとして「Safilia」がリリースされたことをご紹介頂き、さっそく使ってみようということになりました。価格もそれほど高額ではなかったため、すぐに購入することができました。

機能安全設計やASILへの適用について

• – シフターの機能安全について、要求されるASILについて教えていただけませんか？

• 大西様：
  制御を行うECUが付いていない製品であれば、車両への機能安全対応は限定的で、Part5の一部を考慮すればよいのですが、現在のシフターには、制御を行うECUが付いており、制御の挙動が車両の機能安全に関わってきます。制御が予想外の挙動をしてしまうと、車両の挙動にそのまま影響してしまうため、これに対して安全目標の割り当てがあります。クライアントからは機能安全要求が示されます。具体的には、ASILのレベル指定がされることなります。
  
  ASIL-Bへの対応とASIL-Cへの対応には大きな差があります。走る、曲がる、止まるに少しでも関わる制御の場合は、ASIL-C以上が要求されることがあります。クライアントの意向に依存しますが、多くはASIL-Cへの対応が要求されることが多くなってきました。
  
  ただし、例えば、高速走行中にシフターのECUが急にリバースへシフトチェンジする制御挙動を行ったとしても、シフターがつながっているトランスミッションのECUは、ギアを壊してしまうようなギアチェンジを行わない様になっているため、このようなことが考慮できる場合は、シフターの安全要求がASIL-Bになることもあります。
  
  ASIL-Cが要求された場合は、機能安全設計として、弊社のシフター内部の制御に対して、デコンポジション（注：安全要求間でASILを分担すること）を行うことになります。ここに、SCDLに準拠したツール「Safilia 」を使っています。
• 

機能安全設計専用ツール「Safilia」について

• – ガイオの「Safilia」を使うようになって、設計にどのような変化がありましたか？

• 大西様：
  以前のSysMLで記述しようとした時と比較すれば、システムの安全設計が、すんなりと書きやすくなったと思います。SysMLでは、1枚の絵の中にすべての仕様を書き込むような感じで、これを分割しようとすると苦労します。SCDLベースのSafilia を使う場合は、設計内容を分割してシンプルに書くことが容易にできるため、各安全要求の関連が分かりやすく表現できます。入出力に制限をかけることで、さらに安全設計が扱いやすくなります。
  
  詳細なデコンポジションが進み、独立要求が多数出てきた場合や、Part4 にある無干渉の検討を行う場合には、要求図が大きく複雑な構造になります。この分析には、「Safilia」を使ってスコープを絞って設計を進めることで、理解しやすい仕様書を作っています。
  
  具体的には、安全分析は、まず上位の要求関連部分だけにスコープを絞って行い、SM（注：Safety Mechanism）の検討に入る時は、SMの周辺にだけにスコープを絞り直して行っています。SM検討には、SMに関わらないものは全て省略して行い、後で関わりが出るものについては、これを加えていくような方法を取っています。最後に、全体像を示す目的で、すべての設計を合体した1枚の絵を作るようなイメージです。
  
  結果的に、以前のSysMLに比較して、格段に分かりやすい安全設計仕様になっていると思います。
  
  現在のクライアントは海外のお客様です。安全コンセプトを示すに当たり、SCDL自体が浸透しているかと言うとそうではないと思います。この様な状況ではありますが、SCDLベースのSafiliaで書き表した仕様書の見方が分からない等の問題はクライアント間と起こってはおらず、安全設計内容を正しく理解して頂いております。

Safiliaを使うことのメリットについて

• – Safiliaを使ったSCDLに準拠した安全コンセプト設計を行うようになって、以前と比較してどのようなメリットがあったか、教えていただけませんか？

• 大西様：
  SysMLで安全コンセプトを表現しようとすると、１枚の表記では表現しきれず、複数の図を書かなければなりません。これをSCDLで書く場合は、ブロック図の構成の中に、どういったイベントや信号があって、どの様な制約があるかを書くことができるため、ここがSCDLを使う大きなメリットの1つだと思います。経験的には、SCDLで書いた仕様を仮にSysMLで書いたとすると、図の枚数が２倍近くになると思います。設計内容を明確に示すには、枚数の少なさが、大きく影響すると思います。
  
  Safiliaは初期バージョンのR1から使っています。ツールを使うことのメリットとしては、Safiliaは安全コンセプト設計専用に作られていますので、少ない操作で、短時間でできることです。また、最終的に紙に印刷する際には、用紙サイズに自動的に収めてくれるため、非常に重宝しています。
  
  さらに、要求の一覧をエクセルに出力することも可能で、重宝しています。以前は、手作業で要求一覧を作っていましたので、効率が上がりました。Safiliaを使うと、図を修正しただけで、自動的にリンクして一覧表も修正されるため、修正漏れのミスが無くなりました。
  
  未だ使っていないのですが、新しくリリースされたSafilia のインテグレーターでは、要求表や安全侵害の表などを出せるみたいですので、今後、評価してみたいと思います。

弊社ガイオとツールへのリクエスト

• – では最後に、弊社ガイオとSafiliaに対するリクエストがあれば、いただけませんでしょうか？

• Safiliaは未だお絵かきツールの領域にあり、現状では、Safiliaで作成した図を、エクセルで作った安全要求仕様書に張り付けて運用しています。今後は、仕様を示す絵を描くだけではなく、Safilia だけで、機能安全要求を全てまとめることができると良いと思っています。
  
  エディタの内部機能では、インタラクション線の制御がもう少し器用にできないかと思っています。特に、ブロック図の移動やコピーをした際に、接続されているインタラクション線の向きが乱れてしまい、意図通りの方向につながらず、線の修正に時間が掛かっています。この点を改善して頂ければと思います。
• 

まとめ

• 富士機工様はSafiliaの初期バージョンからご導入を頂き、使いこなして頂いているユーザー様です。SysMLによるシステム設計に早くから取り組まれており、メカシフターの時代から電子制御のシフターの時代に変わり機能安全への対応が必要となってからは、いち早くSCDLを取り入れ、要求される安全分析を着実に実施されていることをご紹介頂きました。
  
  ガイオ・テクノロジーとしましては、最後に頂いたご要望を含め、安全コンセプト設計の標準ツールとしてご利用頂けるように、改善に努めて参ります。
  
  【インタビュアーより】
  今回インタビューを受けてくださった富士機工様では、機能安全や開発プロセスの構築を共に担う方を随時募集されているそうです。
  浜名湖が近く、風光明媚な環境で自然に親しみながらエンジニアのキャリアを積みたい方にはピッタリの場所とのことでした。
• 

本稿に関するお問い合わせは

• 本ページ内容に関するお問い合わせは、ガイオ・テクノロジー営業部（ご購入前の製品についてのお問い合わせ窓口）までお願い致します。