JIS F 0075:2003 船舶及び海洋技術―フリートマネジメントシステムネットワークの実施のための指針 | ページ 4

                                                                                             13
                                                                   F 0075 : 2003 (ISO 15849 : 2001)
8. システムハードウェア
8.1   システムハードウェア SITP及びLITP双方に対するシステムハードウェアの選択は,それが稼働
しなくてはならない環境と同様に,FMSによってサポートされるアプリケーションの特質や重要性などに
依存する多くの要因を考慮しなくてはならない。
  この標準では,特定のハードウェアの要件は取り扱わない。
8.2   通信バス 通信バスは,通信ソフトウェア,衛星通信,通常の中長距離無線通信及び携帯電話通信
と同様に,これらと同等のものを含む多くの船舶送受信器間の,物理的インタフェースを提供する。
9. 耐障害性
9.1   耐障害性 それぞれのFMS設備に必要な耐障害性のレベルは,システムによってサポートされるア
プリケーションの重要性の一機能として決定されるべきである。
9.2   強じん(靭)性(ロバストネス) FMSは,基本的に可能な限り強じんに設計されるべきである。
  設計は,システムが故障した場合の容易な回復を考慮しなければならない。もし,システムが故障した
場合でも,FMSは,その機器に,操作者による複雑な再初期化を要求するようなものであってはならない。
10. 実証及び妥当性確認
10.1 一般 FMSを構成する設備及びシステムの,設計,製造及び装備における信頼性の満足度の証は実
証されるべきである。 一般にこの実証は,認証,検証,妥当性確認,試験及び試運転の一連の構成である。
10.2 試験方針 試験は,機器単体レベルから,統合されたシステムレベルの試験を通して,装備された
環境での最終ユーザ試験に至る段階的性質のものである。
10.3 システムハードウェア試験 システムのどの部分も,運用中又は試験中に瞬時の電圧変化で過度の
ストレスにならないことを確認する。
  構成部品が,部品に対して許される状態変数変化,瞬時状態変化,その他の設計上の制約条件,電気的
適合性をもつことを確認する。
  使用温度への安全許容量を確認する。
10.4 LANソフトウェア評価 この指針で使われる,ソフトウェア評価は,FMSソフトウェアの検証と妥
当性確認のための方法論に言及する。
  検証は,機能的な設計に焦点を合わせる。妥当性確認は,システムが必要条件を満たすかどうかに関し
て焦点を合わせる。
  ソフトウェアは,ハードウェアと比べて,磨耗するものでなく,独立した変数内で運用されず,その試
験も,おおむね定性的か推論的であるので難しい。さらに,冗長性は効果的なバックアップにはならない。
  ソフトウェア製品の検証及び妥当性確認は,個別の製品と統合化されたシステムに対して実施されるべ
きである。 そこには,それぞれの装備用として作られた,明確なソフトウェア実証及び妥当性確認試験計
画が準備されることが必要であり,そしてSITP及びFMS構造基盤はその計画に対して試験される。 一
般に,ソフトウェア試験は,次に記述されるように,開発中の三段階で公式に実施されなければならない。
a) 単体試験 ロジックとインタフェース特性を確かめるために,分離した状態での個々のモジュールの
    試験を行う。これはソフトウェア開発と並行して実施される。
b) 統合試験 設計基準に従って,異なったユニットを統合して実施する相互運用性の妥当性検証。
c) 受入れ試験 いかなるシミュレーションの要素もない完全なハードウェア状態,かつ,通常の運用環
    境で,すべてのソフトウェア要素と機能を含めた全体システムの受入れ試験。

――――― [JIS F 0075 pdf 16] ―――――

14
F 0075 : 2003 (ISO 15849 : 2001)
10.5 試験及び試運転
10.5.1 単体試験(α−テスト) これらは,ロジックとインタフェース特性を確かめるために,個々のモ
ジュールと,組合せモジュールの独立した状態での試験をするために必要とされるホワイトボックステス
トである。単体試験は,プロトコルのより低い階層に焦点を合わせ,そして,ソフトウェア設計が許す限
りすぐに始められるべきである。
10.5.2 統合試験 これらは,統合を進めるにつれて種々の階層を結合することを目的とした,ホワイトボ
ックステストである。
10.5.3 エンドユーザ受入れ試験
10.5.3.1 一般 これらは,通信リンクとゲートウェイも同様に,ソフトウェア及びハードウェアを含めた
全体システムの試験である。 それらは,実装されるか,又はシミュレートされたモックアップでとり行わ
れるべきである。FMSとして,これは通常少なくとも一つのSITPと一つのLITPを含む。これらは,10.5.3.2
10.5.3.6までに記述された試験の種類を要求しているブラックボックステストである。
10.5.3.2 ロード/ストレス試験 これは,システムがピークのロード状態(内部及び外部通信量)で処理
することができることを確認するために行われる。
10.5.3.3 セキュリティ試験 これは,セキュリティ管理を壊す繰り返しの試みによって,システムの弱点
を見出すために行われる。
10.5.3.4 性能試験 これらの試験は,ソフトウェアアプリケーション,通信リンク及びデータベース管理
システムのすべてについて行う。
10.5.3.5 ハードウェア適合性試験 これは,必要条件に関して,ハードウェアリソース(メモリ,ディス
ク容量,速度など)の余裕を決めるために行われる。
10.5.3.6 構成試験 これは,ハードウェア又はソフトウェアの構成変更の要求に対して,システムがいか
に反応するか,を見極めるために行われる。
11. 品質計画
11.1 一般 設計,開発,変更,複製及び設置は,品質計画の文書化の対象とするべきである。 少なくと
も,品質計画は性能に対する責任範囲を示すべきであり,11.2の受入れ基準について述べたものである。
11.2 コンピュータサービスの設計及び試験 コンピュータサービスの設計及び試験は,次のことを保証
すべきである。
a) 実施においては,法令や船級協会規則など適用可能な必要条件を満たす。
b) 設計文書は,すべての段階を通して仕様要求を追跡可能であることを示す。
c) モジュールインタフェースと依存関係は明りょうに定義され,そして認識できる。
d) メモリ容量,CPU及びバンド幅の見積もりは信頼性が高く,ハードウェア選定をサポートすることが
    できる。
e) 試験手順は,定義され,そして設計過程で並行して行われる。
f)  文書化は,公式な審査の対象とする。
12. 運用及び保守 システム設計は,システム全体に渡って,運用及び保守の完全な計画を含むべきであ
る。これは,システムの試験での操作マニュアルの使用を含む。保守計画は,システムのための要求され
る保守手順と,適切な参照マニュアルを明らかにすべきである。
13. ヒューマンインタフェース

――――― [JIS F 0075 pdf 17] ―――――

                                                                                             15
                                                                   F 0075 : 2003 (ISO 15849 : 2001)
13.1 一般 SITP及びLITPへのユーザインタフェースの設計では,認知された規格を参照するのがよい。
  FMSNは,運用と利用が,単純で,複雑な操作を必要としないように,設計されるべきである。
13.2 画像表示装置 (VDU)
13.2.1 文字及びグラフィックのサイズ,カラー,コントラスト及びデンシティーは,すべての使用できる
照明状態の下で,操作者の位置から容易に読めて,理解しやすい。字体は,国際的に認知された単純で明
快な設計であるべきである。
13.2.2 VDU各画面は,標準化されたフォーマットにすべきである。 情報と,機能の表示領域は,一貫し
た方法で提示されるべきである。
13.3 画像呼出
13.3.1 総括画面又はそれぞれの画面には,ページングシステムの説明がなければならない。
13.3.2 それぞれの画面のスクリーン上には,独自の識別ラベルが示されるべきである。
14. 訓練及び図書
14.1 一般
14.1.1 FMSのソフトウェア及びハードウェアの技術的な優秀さにかかわらず,操作者の訓練は,その適
用の成功のために不可欠である。
  船舶での運用者の短期従事の性質から,船上の要員に,システムの運用及び保守の十分な訓練がされる
必要性を強調する。
14.1.2 FMSの運用での正式な訓練が可能であるということが,この規格の条件である。
14.1.3 運用管理者及びユーザは,必要とされる程度の,関連するサブシステム,ネットワークの管理機能,
船舶地球局及び陸上の通信ハブのための取扱説明書を含めて,FMSの運用のために段階的な手法で彼らの
知識を,実証しながら訓練されるべきである。 指導のプログラムには,少なくとも次によることを含むべ
きである。
a)   ANの管理
b)   ANの管理
c) クライアント/サーバ システム
d) ネットワークオペレーティングシステム
e) すべての装備されたハードウェア
f)  保守及び修理
g) 電気通信に関する規則の知識
h)   ITP及びFMSシステム管理
i)  データベース管理
14.2 図書
14.2.1 図書は,“情報システムの構造と使用目的,又はその構成要素の理解のために提供された手引書”
及び“要求,能力,限界,設計,運用及び情報処理システムを記載した文書集”としてのシステム文書と
して定義することができる。
  いずれの定義も,この規格の目的のために重要である。
14.2.2 SITPのためのユーザ図書は,自己学習の形で,許されたすべての操作と,それらのシステムの調
整又は修理のための詳細説明書を含み船上要員にふさわしいもので提供される。

――――― [JIS F 0075 pdf 18] ―――――

16
F 0075 : 2003 (ISO 15849 : 2001)
14.2.3 FMSのための運用管理者用図書は,ユーザ図書に加えて更に,システムを管理するために必要な
完全な参照資料を含むべきである。

――――― [JIS F 0075 pdf 19] ―――――

                                                                                             17
                                                                   F 0075 : 2003 (ISO 15849 : 2001)
                                    附属書A(参考)
まえがき この附属書は,フリートマネジメントシステムネットワーク (Fleet Management System
Network  : FMSN) の実施のための指針 (JIS F xxxx) の実行に当たり,ネットワークの相互接続性を確保
するための実効ある透過性を実現するために,SITP及びLITPを適用して,アプリケーションプログラム
インタフェース (Application Program Interface : API) を作成する場合の,ソフトウェアの設計仕様の一例を
示すものである。
A.1 適用範囲 本体で規定する,SITP及びLITPで定義された機能に適用するAPIの目的のためのソフト
ウェア設計指針。
  この附属書では分散型オブジェクト仕様としてCORBAの使用を前提としている。
A.2 定義 この附属書で用いる用語の定義は,次による。
A.2.1 データ一覧取得 指定したサーバに属するデータベースに格納されている,データの一覧リストを
取得するオペレーション。
A.2.2 船舶情報取得 指定したサーバからの問い合わせオペレーション。
A.2.3 CORBA (Common Object Request Broker Architecture)   MG (Object Management Group) の定め
る分散オブジェクトモデルの標準。
A.2.4 データベースサーバ データベースを内蔵するシステム。この附属書では特にLITP搭載システム
やSITP搭載システムとは独立した端局にデータベースが配置される場合,その端局をデータベースサー
バと呼ぶ。
A.2.5 IDL (Interface Definition Language)   ORBAの言語の相違を保護するための主要なツールで,それ
ぞれのオペレーションのインタフェースを定義するための言語。
A.2.6  IDLスケルトン CORBAを利用してクライアント/サーバ間通信を行う場合に,サーバ側のプロ
グラム(この附属書ではAPI部)が提供する各オペレーションを直接起動するプログラム。
A.2.7 IDLスタブ CORBAを利用してクライアント/サーバ間通信を行う場合に,クライアント側のプ
ログラム(この附属書ではAPI部)に対してサーバ側のオペレーションへのアクセスを提供するプログラ
ム。
A.2.8 ネーミングサービス CORBAが提供する共通サービスの一つ。特定オブジェクトからの問い合わ
せに対して,オブジェクト名に対応するネットワーク中のロケーションを返すサービス。
A.2.9 ネーミングサービスインタフェース APIがユーザアプリケーションからの要求を受けて行う一連
の処理の中で,ネーミングサービスを利用する際に動作するプログラム。
A.2.10 OMG (Object Management Group) オブジェクト指向技術や異機種分散環境におけるアプリケー
ションの開発に必要な,インフラストラクチャーのための技術を規定している国際的な標準化団体。
A.2.11 ORB (Object Request Broker) スタブとスケルトン間の通信機能を提供する。
A.2.12 データ読出 指定したサーバに属するデータベースから,要求中に指定される一個のデータを取
得するオペレーション。
A.2.13 ユーザアプリケーション FMSNにおいてLITP搭載システムが要求する機能(“運航管理情報取

――――― [JIS F 0075 pdf 20] ―――――

次のページ PDF 21