Posts Tagged with "ISO 26262"

既に発行済みのブログであっても適宜修正・追加することがあります。
Even in the already published blog, we may modify and add appropriately.
posted by sakurai on September 13, 2018

ISO 26262のPMHFの導出の場合、微小確率の積分を実行する際に次の(60.1)及び(60.2)式が出てくるため、あらかじめ結果を導出しておきます。 $$\frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(t) f_{M}(t)dt\tag{60.1}$$及び$$\frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(u) f_{M}(t)dt, ただしu=t\bmod\tau_{SM}\tag{60.2}$$ まず、(60.1)式は、 $$\frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(t)f_{M}(t)dt=\frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}\left[1-\exp(-\lambda_{SM}t)\right]\lambda_{M}\exp(-\lambda_{M}t)dt \\ =\frac{\lambda_{M}}{T_{lifetime}}\int_0^{T_{lifetime}}\exp(-\lambda_{M}t)dt-\frac{\lambda_{M}}{T_{lifetime}}\int_0^{T_{lifetime}}\exp\left[-(\lambda_{SM}+\lambda_M)t\right]dt\tag{60.3}$$ (60.3)の右辺第1項は、(Mathjaxのバグ?により一行で書くとエラーとなる) $$\text{1st term of RHS of (60.3)}=\frac{\lambda_{M}}{T_{lifetime}}\left[\frac{\exp(-\lambda_{M}t)}{-\lambda_{M}}\right]^{T_{lifetime}}_0$$

$$=\frac{1}{T_{lifetime}}(1-e^{-\lambda_{M}T_{lifetime}})\tag{60.4}$$ (60.3)の右辺第2項は、(Mathjaxのバグ?により一行で書くとエラーとなる) $$\text{2nd term of RHS of (60.3)}=\frac{\lambda_{M}}{T_{lifetime}}\left[\frac{\exp(-(\lambda_{SM}+\lambda_{M})t)}{-(\lambda_{SM}+\lambda_{M})}\right]^{T_{lifetime}}_0\tag{60.5}$$

$$=\frac{\lambda_{M}}{T_{lifetime}(\lambda_{SM}+\lambda_{M})}\left[1-e^{-(\lambda_{SM}+\lambda_{M})T_{lifetime}}\right]$$ ここで$\lambda t\ll 1$の条件で$e^{-\lambda t}$のMaclaurin展開は $$e^{-\lambda t}=1-\lambda t + \frac{1}{2}\lambda^2 t^2-O(t^3)$$となるため、$O(t^3)\approx 0$と近似し、これを(60.4)及び(60.5)に代入すると(60.3)は、

$$\frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(t) f_{M}(t)dt\approx\frac{1}{2}\lambda_{M}\lambda_{SM}T_{lifetime}\tag{60.6}$$

結果の対称性から推測可能なように、(60.6)においてMとSMを入れ替えた次の式も同じ値となります。 $$\frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{M}(t) f_{SM}(t)dt\approx\frac{1}{2}\lambda_{M}\lambda_{SM}T_{lifetime}\tag{60.7}$$

次に(60.2)式はやや複雑になりますが、同様に計算を行うと、次式が求められます。

$$\frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(u) f_{M}(t)dt\approx\frac{1}{2}\lambda_{M}\lambda_{SM}\tau_{SM}\tag{60.8}$$

これも結果の対称性から推測可能なように、次の式も同じ値となります。 $$\frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{M}(t) f_{SM}(u)dt\approx\frac{1}{2}\lambda_{M}\lambda_{SM}\tau_{SM}\tag{60.9}$$


左矢前のブログ 次のブログ右矢

posted by sakurai on September 10, 2018

SMのアンナベイラビリティ(不稼働率、PUA)$Q_{SM}(t)$の導出

以前PMHF式を以下で導出しました。 https://fs-micro.com/post/show/id/10.html

ここでは再度PMHFの式を導出して行きますが、事前準備がいくつか必要になりますので、まず、修理系のアンナベイラビリティの公式を導きます。

まず、修理系とは何かを説明します。ISO 26262規格には修理の問題についてはっきり書いていませんが、1st SMが修理系となります。1st SMとは、1st order SMとも呼ばれ、主機能のSG侵害を防止するためのSMです。一方で、主機能は非修理系です。

1st SMは、2nd SMにより定期的に検査され、故障だと判明した場合は直ちに修理されます。2nd SMとは2nd order SMとも呼ばれ、エレメントがレイテントフォールトとなるのを防止する安全機構です。規格にもあるとおり、修理周期は「検査周期($\tau_{SM}$)+ドライバーが修理工場へ運転して行く時間+修理にかかる時間」です。従って、修理周期=2nd SMの検査周期とみなせます。

規格にははっきり書かれていませんが、検査により故障と判明した部分については、修理され新品同様(as good as new)と見なされます。この検査による故障検出割合が重要であり、Part 10では定数値$K_{FMC,MPF}$で表されます。故障したうちの検出部分なので(59.1)のように条件付き確率と考えがちですが、 $$K_{FMC,MPF}=\Pr\lbrace \text{detectable}\ |\ \text{failed at }t \rbrace\tag{59.1}$$ 故障検出能力は確率的に決まるものではなく、アーキテクチャ的に決まるものだと考えるため、もともとの検出部分の故障について検出可能とします。 $$K_{FMC,MPF}=\Pr\lbrace \text{detectable} \rbrace\tag{59.2}$$ 検出された故障は全て修理されるものとします。 $$\Pr\lbrace \text{repaired}\ |\ \text{detected at }t\rbrace=1\tag{59.3}$$

次にアンナベイラビリティ$Q_{SM}(t)$とは、省略せずに言うとポイントアンナベイラビリティ(PUA)であり、修理系の不稼働率です。 確率の式で表せば、

PUA: $$Q_{SM}(t)\equiv\Pr \lbrace \text{(repairable)SM down at }t \rbrace\tag{59.4}$$ のように、時刻$t$において不稼働である確率を意味します。

一方で、PUAの式は教科書等を参照すれば、 $$A(t)\equiv R(t)+\int_0^t m(x)R(t-x)dx\tag{59.5}$$ であり、ここで、$A(t)$は時刻tにおけるポイントアベイラビリティ、$R(t)$は時刻tにおけるリライアビリティ(信頼度)、$m(t)$は時刻tにおけるリニューアル密度(修理密度)です。規格の特徴として、修理周期は教科書一般にあるように指数関数分布はとらず、定期的に$\tau_{SM}$で行われるため、以下の式が成立します。 $$A_{SM}(t)=R_{SM}(t)+\img[-1.35em]{/images/withinseminar.png} \tag{59.6}$$ 修理分が時刻$t$の関数でないのは、検出能力$K_{FMC,MPF}$は一定で、毎回検出した分は全て修理されるため、修理分は一定となるためです。 SMのポイントアベイラビリティ式は以下のようになります。 $$A_{SM}(t)dt=\img[-1.35em]{/images/withinseminar.png}\tag{59.7}$$

これを1から引けば、SMのポイントアンアベイラビリティ(PUA)は以下のように求められます。

PUA: $$Q_{SM}(t)dt=\left[1-A_{SM}(t)\right]dt=\img[-1.35em]{/images/withinseminar.png}\tag{59.8}$$

ここでの議論において、次に示すような形式的な記法を用いています。例えば、 $$f(t)=\lim_{dt\to +0}\frac{F(t+dt)-F(t)}{dt}=\frac{dF(t)}{dt}$$ と書くところを$dt$が無限小であることを前提として、 $$f(t)dt=(\frac{dF(t)}{dt})dt$$ としています。確率密度関数$f(t)$を求めるよりも、微小確率$f(t)dt$を求めるほうが、次で積分の記述が容易になるためです。


左矢前のブログ 次のブログ右矢

共存の基準(2)

posted by sakurai on September 8, 2018

アセッサー目線からみると、ASILが食い違うところはまずチェックします。当然ですが、低ASILから高ASILの、例えば図のように、ASIL-Bのエレメントからの信号をASIL-Cのエレメントで受けているような場合。しかしながら、規格Part9 6.4で述べられているように、QMないし低ASILの要求を割り当てられたエレメントは、ASILないし高ASILの割り当てられたエレメントへ干渉してはいけません。

図58.1
図58.1 エレメントAからエレメントBへ干渉が起きる場合

干渉がある場合には、エレメントを高いASILへ引き上げる必要があります。これが前回も述べた、共存の基準と言われる規格要件です。

専門家(日本の機能安全関連団体の委員)の資料で、「干渉は従属故障が無いこと」と書いてあるものを見ましたが、これは誤りです。無干渉とは、Part1-1.49に示されるとおり、カスケード故障が無いことです。従属故障というと、カスケード故障と共通原因故障の両方を含みます。 また同じ資料で、「干渉は片方からの故障の影響であり、独立は相互に故障の影響が無いこと」と書かれていましたが、これも誤りで「独立とは従属故障が無いこと」と規格で定義されています。

このように、専門家といえども規格の文言を誤解していることが無いとは言えないので、盲信せず聞く必要があると思われます。


左矢前のブログ 次のブログ右矢

共存の基準

posted by sakurai on September 1, 2018

デコンポジションの基本的な考え方は理解頂いたと思うので、同様に重要な要件を説明します。 同じくPart9に記載されている「共存の基準」です。

  1. QMエレメントからASILエレメントへの無干渉を証明すれば、QMエレメントとASILエレメントが共存することができる。さもなければQMエレメントはASILエレメントのASILまでASILを引き上げなければならない。

  2. 低ASILエレメントから高ASILエレメントへの無干渉を証明すれば、低ASILエレメントと高ASILエレメントが共存することができる。さもなければ低ASILエレメントは高ASILエレメントのASILまでASILを引き上げなければならない。

いずれも同様な要件であり、QMないし低ASILエレメントはいわば濁った水です。一方で高ASILエレメントはきれいな水です。従って、高ASILエレメントがQMないし低ASILエレメントに干渉しても、濁ったままで問題ないのに比べて、その逆の場合は、きれいな水が濁った水になってしまいます。従って、無干渉が証明できない限り濁った水をきれいにしてやる必要があるということです。

図57.1

規格Part9 6.4.4及び備考1を見てみましょう。

図57.2
図57.3

これはQMからASIL付与エレメントへの無干渉条件(カスケード故障無き事)ですが、前述のとおり、低ASIL付与エレメントから高ASIL付与エレメントへの同様の条件があります。それが規格要件Part9 6.4.5です。

図57.4

左矢前のブログ 次のブログ右矢

ASILデコンポジション(2)

posted by sakurai on August 27, 2018

前回は規格の条文に基づいて、ISO 26262におけるASILデコンポジションの原則を説明しましたが、実際にどのように設計するかをお話しします。

あるECUがあり、それに対するASILは最高ASILであるASIL-Dだとします。その理由は、このECUが走る、曲がる、止まるに関係しており、高速道路上で故障した場合に、人命に影響するためです。安全目標はそのように定められており「意図せず走行中にECUからアクチュエータへ特定機能のON信号を出力しないこと」となります。本機能はマイコンのソフトウェアで実装されています。

注意点として、ASILデコンポジションはシステマティック故障が対象なので、主にソフトウェア開発のASIL引き下げに有効です。従ってこのマイコンのASILを下げることを考えます。

マイコンはノイズ等で誤動作する可能性があることから、まず初期安全要求を冗長化します。マイコンへの初期安全要求は「意図せず走行中にマイコンから特定機能のON信号を出力しないこと」。ここで、「意図せず」というのは、「設計意図と異なり」という意味で、実際には「故障したとき」と読み替えると意味が通ります。「意図せず」という文言は省略されることがあります。

冗長化された安全要求はTSR1=「走行中にマイコンから特定機能のON信号を出力しないこと」、TSR2=「走行中にマイコンから特定機能のON信号を出力しないこと」と同じ内容の安全要求となります。これをエレメント独立要求を満足するようにエレメント分割すると、メインマイコンとサブマイコン、ないしはメインマイコンとハード制御と分割できます。このRBD(Reliability Block Diagram)を書けば、言うまでもなく並列系となります。

図56.1

ここではハード回路で制御する方法を考えると、走行中にマイコンからの特定機能のON信号のスイッチを切れば良いわけで、比較的簡単な回路で実装可能です。当然、メインマイコンとハード回路の間は独立性が必要であり、独立とはカスケード故障と共通原因故障のいずれもなきことを意味します。

ここで、規格のPart9 5.4.7 a)にあるように、安全機構のASILを高くしてASIL-D(D)、マイコンをQM(D)とデコンポジションすることができます。マイコンのソフトウェアは従来開発を流用できるため、コストの高い機能安全開発から免れることができます。

図56.2

左矢前のブログ 次のブログ右矢

ASILデコンポジション

posted by sakurai on August 23, 2018

ASILデコンポジションについて、誤解が幅広くみられるため、説明したいと思います。

誤解の例1

あるティア1では、ECUを設計する際にOEMから安全目標を頂いたところ、ASIL-Cでした。走る曲がる止まるに関連し、もし故障した場合のリスク度合が高いため安全目標がASIL-Cとなっています。ところで、ASIL-CのSPFMの目標値は97%以上と非常に高く、ほぼすべてのエレメントが故障検出されるといっても良いくらいです。また最高難度であるASIL-Dの99%以上と比べてほとんど違いが無いため、欧州ではASIL-CとASIL-Dは同様なプロセスやアーキテクチャを適用することが多いようです。

本来、安全目標があり、それをシステムレベルの初期安全要求に分解しますが、安全要求がASILの属性を持つことに注意してください。エレメントは安全要求を割り当てられてはじめてASIL値を持つことになります。

つまり、要求も無しにエレメントのASILを決定することはできません。このティア1では、MCUは従来開発を踏襲したいのでMCUにQMを割り当てました。先にエレメントのASILを決めてしまいましたが、これでは本末転倒です。

一方、これはある意味理解でき、ソフトウェアは安全機構でバックアップした上で、なるべくQMで開発したいところです。そのためにISO 26262規格ではASILデコンポジション(ASIL分解)というテーラリング手段が用意されています。

ただし、ASILデコンポジションが可能なのは以下の2つの要件が満足されるときに限られます。

  1. 安全要求の冗長性
  2. 安全要求の割り当てられたエレメント間の独立性

まず、1.は規格Part9 5.4.4に

図55.1
図55.2

とあります。普通の場合、初期安全要求は複数の安全要求に分解され、分解された安全要求を合わせて初期安全要求を満足します。ASILデコンポジションは例外で、分解された安全要求は「単独で」初期安全要求を満足しなければなりません。備考にもあるようにこれは冗長性を意味します。これは、エレメントの機能失陥により一方の安全要求が達成されなくても、他方の安全要求が割り当てられたエレメントにより初期安全要求が担保されることを意味します。

次に2.は規格Part9 5.4.6に

図55.3

とあるように、分解された安全要求が割り当てられたエレメントはお互いに独立でなければなりません。独立とは、Part9 5.4.11 b)にあるように、従属故障分析を行った上で、その故障原因を発見できない場合、あるいはコントロールされる場合という意味です。この従属故障とは、カスケード故障と共通原因故障の両者を意味します。

図55.4

これら2つの要件をまとめて表すと次の規格要求となります。

図55.5

左矢前のブログ 次のブログ右矢

Zynq UltraScale+ MPSoC

posted by sakurai on April 28, 2018

FPGAボード

プロセッサを含んだFPGAボードを入手しましたので、お約束のLED点滅を実験してみたいと思います。 まず、FPGAは、XilinxのZynq UltraScale+ MPSoCという部品で、ARM Cortex A53のクアッドコアとARM Cortex R5のデュアルコアを内蔵しています。

ボードの詳細は以下にあります。 http://microzed.org/product/ultrazed-eg-starter-kit

ベースボードとメザニンボードから構成されており、ベースボードの資料は、 http://picozed.org/product/ultrazed-eg-io-carrier-cardに、 メザニンボードの資料は http://microzed.org/product/ultrazed-EGにあります。

メザニンボード上にFPGA、SDRAM、Flash等が搭載されており、ベースボード上には各種高速インタフェースが搭載されています。

図FPGAボード
図39.1 FPGAボード

開発環境

最近のFPGAの開発環境の進歩はいちぢるしく、従来は高価なEDAツールが無償で使えるようになりました。XilinXが無償で提供しているVivado HLx WebPackが、上記FPGAの開発ツールです。このツールには論理合成ツール、配置配線ツール、論理シミュレータ等が含まれます。特に、最近は高位合成ツールまで無償で使用できるので、隔世の感があります。高位合成までいかなくても強力なIPインテグレータが搭載されており、従来はRTL設計するしかなかった各種AXIインタフェースに関して、単にブロックをドロップし、auto connectをクリックするだけで自動結線する、強力な機能を持ちます。

Vivadoの入手はXilinxにアカウントを作成する必要がありますが、無償ですので以下からwebpackを入手してください。 https://japan.xilinx.com/products/design-tools/vivado/vivado-webpack.html

IP Integrator

IPインテグレータでブロック設計をした結果を以下の図に示します。FPGA全体はPS(Processor System)部とPL(Plogrammable Logic)部から構成されていますが、ZynqはFPGA全体ではなく、PS部のみです。blinkはRTLで設計するブロックで、PL内に配置します。

ブロック図
図39.2 ブロック図

Zynqをダブルクリックすると以下の図のようにブロック図が現れます。APUはApplication Processing Unit、RPUはRealtime Processing Unitの略で、それぞれCA53、CR5及びそのキャッシュシステムを意味します。今回はハードのみで動作する回路を設計するため、プロセッサは全く使用しません。

Zynq内部ブロック図
図39.3 Zynq内部ブロック図


左矢前のブログ 次のブログ右矢

MBSEとSysML

posted by sakurai on March 21, 2018

MBSE

モデルベースデザインの成功例としてマツダの例がしばしば取り上げられます。主任設計者の方のインタビューでは、「金が無いからモデルベースを進めた」ということをおっしゃられていました。実機を作成するには費用がかかりますが、時間もかかります。モデルであれば、作成も修正も(慣れれば)容易です。結果的にModel In the Loopの手法で他社よりも早く開発することができました。モデルベースの開発のメリットは早さだけでなく、ステークホルダー(利害関係者)の間で仕様の認識違いの無いことを、従来の自然言語ベースの仕様書よりも担保しやすくなります。一方で、従来のドキュメントよりも抜け漏れが無いように作りこむことから、しばしば工数は(そこだけ見ると)増加します。

SysML

従来モデル記述言語にはUMLがありましたが、UMLはその仕様が大きくて使いにくい面があり、近年はSysMLを使うユーザが増加しています。SysMLは2006 年 7 月に OMG (Object Management Group) により仕様が策定された言語でUMLを一部使いやすく制限し、一部で拡張しています。拡張の部分の大きな点は要求図を入れたことであり、これは大きな進歩だと考えています。なぜならISO 26262では安全要求ベースで開発が進むためです。具体的には、大きな安全要求、つまり大目標のことを安全目標と呼び、それを抽象度を下げることにより、細分化していきます。抽象度を下げるとは、最初機能であったエレメントのつながりが、最後には物理的なエレメントのつながりに変化していくことを意味します。つまり、要求の抽象度を下げるというよりも、それを割り当てるエレメントを細分化していき、結果として要求が細分化されます。その中で、機能であったエレメントがハードエレメント、ソフトエレメントに細分化されます。

これは設計プロセスそのものですが、抽象的に表現してもわかりにくいので、前回は出張を例にとり具体的な例で示しました。

SysMLに関して大変参考となるページがあるので、ご紹介します。

http://www.ogis-ri.co.jp/rad/webmaga/rwm20100806.html


左矢前のブログ 次のブログ右矢

要求と要件

posted by sakurai on December 28, 2017

要求

要求について考えてみましょう。ところで似たような言葉に要求と要件とがあります。似たような概念であるため、混用して使用されることも多いですが、ここでは異なる意味として定義をはっきりさせておきたいと思います。

まず要求ですが、顧客の要求を意味することが多いです。顧客要求は文字通り顧客の要望であり、それは整理されておらず、たまには矛盾する要望が存在します。それが開発側に伝えられるわけですが、開発側はそれをシステマティックに整理し、矛盾は取り除き、開発側の要件とします。従って、同一のようなものでありながら、顧客からリリースされた時点では要求であるのに比べて、要求分析を実施し、再定義することにより再定義することで要件となります。

仕様

それでは仕様とは何でしょうか。要求も仕様も、これもまた混用して用いられますが、本来ははっきりと異なった意味があります。以下の参考URLを見て頂ければわかりますが、端的には要求(要件)はWhatであり、仕様はHowだということです。要求は、方法はともかくこのように動いて欲しいという振る舞いを機能的に(=機能要求)、非機能的に(=非機能要求)表すのに対して、仕様はどのようにそれを実施するかを記述します。

https://wellfire.co/learn/requirements-and-specifications/

要求と仕様の具体例

要求を細分化して実現可能な仕様に落としていく作業のことを「設計」と呼びますが、抽象的な概念であるため、理解のために具体例を挙げてみます。例えばあなたが支社に勤務しているとして、上司から「本社に出張してくれ」と言われたとします。まぎれもなくこれは要求です。手段はどうあれ、物理的に移動することが目標となります。もちろん、暗黙の非機能要求として「時間、費用を最小にしてくれ」という要求もあります。従って、支社から本社に一足飛びにヘリコプターで行くのは採用できません。公共交通機関を利用するとして、支店もよりのA駅、本社最寄りのB駅を結ぶ鉄道を思い浮かべます。

この頭の中で一瞬で行うのはおおまかな「支社→本社」という要求を実現可能な手段に合わせて「支社→A駅」(徒歩)、「A駅→B駅」(鉄道)、「B駅→本社」(バス)という要求に分割したことにほかなりません。これは出張を設計したことになります。

安全設計

ここまでは機能安全に関係ない、一般の設計でしたが、ここからが関係してきます。出張においての安全設計とはなんでしょうか?例えば前記本社への出張で、鉄道が不通になったら「鉄道が不通になったのでいけません」ということになります。重要な会議の場合は「なんとしてでも行ってくれ」ということになると思います。 機能安全では回路の中でも重要とそうでないものを識別するように要求されており、安全に関連するものとしないものを区別する必要があります。安全に関連するものは、場合によってはどうしても達成する必要があります。この場合のどうしてもというのは、例え一点故障があってもの意味合いです。 さて、出張に戻り安全設計を考えると、本来の要求の冗長の要求を導出します。導出といっても同じ要求のコピーです。ただし、異なる手段が必要となります。例えばA駅とB駅間で私鉄とJRが並走していれば、別の鉄道を使うことになります。そうでない場合は、例えば「支社→C駅」(バス)、「C駅→D駅」(別の鉄道)、「D駅→本社」(バス)ということになります。


左矢前のブログ 次のブログ右矢

posted by sakurai on November 17, 2017

システム工学

近年システム工学の隆盛により、自動車分野にもその流れが来ています。その中で、次第に上流まで言語設計をする動きがあります。その理由は、従来ドキュメント(紙)により仕様を関係者に伝え、順次具体化して来ていたわけですが、その行き詰まりが、特にソフトウェア分野で顕著なためです。関係者の例としては顧客、サプライヤー間、サプライヤー、ソフトウェアハウス等があり、様々な局面で仕様がブレークダウンされ取り交わされます。

車載ECUの開発は、ハードウェアよりもソフトウェアに多大な工数がかかるのは良く知られており、デバッグに大変な労力をかけています。それは仕様の思い違いだったり、ユースケースの抜け漏れだったり、単なる論理ミスだったり様々な原因がありますが、仕様に関するものだと、場合によるとテストもその仕様で作成された場合にはテストでバグを検出することができません。

バグは入れなければ取る必要も無いことから、ソフトウェアの自動生成が考えられてきました。このようにしてコンピュータの言語の歴史はコンピュータに近いほうから、アセンブリ言語、コンパイラ言語、システム言語(ドメイン固有言語)と進化してきました。システム言語は、人も含めたあらゆるシステムを、ユースケース図、シーケンス図、状態遷移図、ブロック図等の人間が紙に記述してきたドキュメントをなるべく形式的な形で、自然言語を使わない形でコンピュータに取り込むことを目指しています。この取り込む形のことをモデルと呼び、ここで述べたような設計手法のことを、モデルベースシステム工学、簡単にはモデルベース設計と呼びます。


左矢前のブログ 次のブログ右矢


ページ: