このページの内容は最新ではありません。最新版の英語を参照するには、ここをクリックします。

電気自動車充電器のロック機構の形式的要件についての解析

R2022a 以降

この例では、Requirements Tableブロックを使用して、電気自動車充電器のロック システムのモデルで使用される形式的要件のセットを定義します。ロック システムの形式的要件を作成した後、要件を解析して、完全で一貫した要件にならない問題がないか確認します。問題を特定したら、要件を調整します。

電気自動車の充電時は、車両の充電ポートに高い電圧がかかるため、適切な対策が施されていなければ利用者が危険にさらされることになります。充電器や電気自動車には、そのような電圧から利用者を保護するためにロック機構が配備されています。ロック機構がアクティブおよび非アクティブになるときに危険が生じないように、充電前、充電中、および充電後に充電ステーションから車両に信号が送られます。車両では、それらの信号を使用して、充電コードのロックを解除して安全に取り扱えるタイミングを判別します。

形式的要件の確認

モデル CordLockReqTable_v1 を開きます。

open_system("CordLockReqTable_v1");

このモデルでは、SAE J1772 規格 [1] の充電ステーションで使用される信号を応用しています。それらの信号を取得するために、Requirements Table ブロックで同じ名前の入力データに関連付けられた 6 つの入力端子を使用しています。Requirements Table ブロックのデータの定義を参照してください。

入力データは次のとおりです。

• ChargeStatus:車両の充電ステータス。このステータスは車両側の状態を示し、充電中でない (NotCharging)、充電中 (ChargeStart)、停止中 (NrmlShutDown)、緊急停止の実行中 (EmrgShutDown) のいずれかになります。

• EvseType:車両に充電ステーションとの互換性があるかどうか。車両は Compatible、Incompatible、または NotDecided (未判定) のいずれかになります。

• PilotStatus:充電ステーションのパイロット ステータス。パイロット ステータスは充電ステーション側の状態を示し、充電ステーションが待機状態である (A)、充電ステーションが車両を検知している (B)、充電ステーションが車両を検知して車両側の充電準備ができている (C)、充電ステーションが車両を検知して換気の良い場所で車両側の充電準備ができている (D)、エラーがある (E_F) のいずれかになります。ステート B、C、および D には、それぞれ 2 つのサブステートがあります。サブステート 1 は充電ステーション側の充電準備ができていないことを示し、サブステート 2 は充電ステーション側の充電準備ができていることを示します。

• SessionStopResMsg:充電セッションの終了について充電ステーションで肯定応答された (Received) か肯定応答されていない (NotReceived) か。

• Vinlet:車両で測定された充電ポートの電圧。

• LockCommand:ロックのステータス。ロックは Locked または Unlocked のいずれかになります。

ブロックは、入力データの値を使用して、データの [タイプ] プロパティを MATLAB® プログラム ファイルで指定されている列挙値に設定します。たとえば、ChargeStatus データの使用可能なステータスは ChrgStat.m ファイルに格納されています。

ブロックを開いて要件を確認します。[要件] タブに 3 つの単純な要件がリストされます。

1. 電気自動車の供給装置に互換性があれば、電気自動車のコードを所定の位置にロックする。

2. 充電セッションの終了に対する肯定応答の信号を受信した場合、車両での入力電圧の測定値が 60 V 未満であれば、通常の停止手続きで電気自動車のコードのロックを解除する。

3. パイロット ステータスが準備できていない状態の場合、車両での入力電圧の測定値が 60 V 未満であれば、緊急停止で電気自動車のコードのロックを解除する。

各要件の [前提条件] 列で、チェックされる条件が指定されます。要件の前提条件を満たす場合、ブロックで事後条件が検証され、[事後条件] 列で指定された該当するロック ステータスが発生するかどうかが確認されます。たとえば、最初の要件では、指定された前提条件で車両タイプに互換性があるかどうかがチェックされます。true の場合、事後条件の指定に従って、コードがロックされているかどうかがブロックでチェックされます。

要件の問題についての解析

ブロックで要件セットを作成した後、ブロックによって取得、格納、生成されるデータが要件で一意に定義されていることを確認します。この例では、Simulink® Design Verifier™ を使用して要件セットの問題を検出します。これらの問題は、ISO/IEC/IEEE 29148 規格 [2] から応用したものです。この例では、Simulink Design Verifier で 2 種類の問題が検出されます。

1. 不整合の問題: シミュレーション時にデータが複数の値と等しくなる可能性があるシナリオがブロックで検出されます。

2. 不完全性の問題: シミュレーション時にデータが定義されないシナリオがブロックで検出されます。

テーブルを解析するには、[テーブル] タブの [解析] セクションで [テーブルの解析] をクリックします。

要件の更新

問題を解決するには、要件を更新する必要があります。たとえば、不整合の問題を軽減するには、最初の要件の前提条件を更新し、充電ステータスが充電中であること、および充電器に車両との互換性があることを条件にします。

前提条件を更新した後、解析を再度実行して、整合性の問題が解決されたことを確認します。

この更新では不完全性の問題は解決しません。そのためには、シミュレーション全体を通じてブロックで定義されるデータの値を要件で指定する必要があります。要件の更新と解析を反復し、それらの残りの問題を解決します。

モデル CordLockReqTable_v2 を開き、Requirements Table ブロックを開いて完全な要件セットの例を確認します。

open_system("CordLockReqTable_v2");

テーブルには、コードが車両に接続されている (Plugged) か接続されていない (NotPlugged) かを示す追加の入力データ ChargePlug が含まれています。また、要件セットに 5 つの追加の要件が含まれています。読みやすくするために、追加の列ヘッダーを使用して要件を書き直してあります。

要件を設計するときは、システムの物理的な制限を考慮する必要があります。たとえば、直径を指定する要件を開発する場合は、直径が負にならないようにしなければなりません。システムの物理的な制限を考慮するには、[仮定] タブで仮定を指定します。要件への仮定の追加を参照してください。この例では、Requirements Table ブロックに 3 つの仮定が含まれています。

1. パイロット ステータスが待機状態 (A) であれば、車両は充電中でない。

2. 車両に充電器との互換性がなければ、車両は充電中でない。

3. 充電器が接続されていなければ、車両は充電中でない。

仮定を確認するには、[仮定] タブをクリックします。

この要件セットについて解析を実行した場合、Simulink Design Verifier で問題は検出されません。

参照

[1] Hybrid - EV Committee, “SAE Electric Vehicle and Plug in Hybrid Electric Vehicle Conductive Charge Coupler” (SAE International), accessed December 21, 2021, https://doi.org/10.4271/J1772_201710.

[2] “29148-2018 - ISO/IEC/IEEE International Standard - Systems and Software Engineering -- Life Cycle Processes -- Requirements Engineering” (IEEE), accessed December 21, 2021, https://doi.org/10.1109/IEEESTD.2018.8559686.

参考

Requirements Table

関連するトピック

• Requirements Table ブロックを使用した形式的要件の作成
• 要件への仮定の追加
• 矛盾する形式的要件セットおよび不完全な形式的要件セットの特定
• Requirements Table ブロックのデータの定義