• Coppell Technologies

    Coppell Technologies

    Data Model Use Cases

    • トップ
    • 1. データモデルの共通パーツ
    • 2. 推奨データセット
    • 3. 公共施設管理

    Menu


    Coppell Technologiesトップ
    Fiwareで都市OSを動かしてみよう
    NGSI-LDにも挑戦
    データ仕様の現状と課題
    データ交換の標準規格 (案)

    Data Model Use Cases
    ユースケース
    • トップ
    • 1. データモデルの共通パーツ
    • 2. 推奨データセット
    • 3. 公共施設管理
    • 3. 公共施設管理
    •  3.1. データモデル - 基本情報
    •  3.2. データモデル - 公共施設管理
    •  3.3 列挙型項目のメンバ定義

    Column
    Link集
    用語集

    Coppell

    Technologies

    3. 公共施設管理


    2022-09-15

     本ユースケースは、自治体などが保有する施設の管理を民間の委託する際に、自治体と民間、民間の会社間のコミュニケーションを図るだけでなく、日々の活動に際して発生するデータを蓄積し、ビックデータなどでの活用を企図するものです。




    想定業務
    2022-09-15

    • 自治体が保有する市役所や公民館などの公共施設の管理を行う業務。本業務は自治体、維持管理事業者、および委託事業者が共同で行う。
    • 維持管理事業者は、施設および施設に設置している設備や環境が正常に稼働している状況を、委託事業者と連携して点検・修理・修繕・植生・清掃・警備などの活動を通じて維持すると共に、自治体や住民に対する窓口を設定し、故障の連絡や要望を受け付けて対処する
    • 自治体は、維持管理事業者に施設に関する設置場所・名称・構造・設備などの情報を事前に提供する。提供された情報が、施設の維持管理を効率よく実施するに十分ではない場合は、維持管理事業者は追加計測を実施するなどにより補強する
    • 委託事業者は、点検・修理・修繕・植生・清掃・警備などをの実施する。
    • 維持管理事業者は後述するFMシステムを委託事業者に提供する事により、委託事業者の作業結果はpdf等の電子文書ファイルにより報告され、更に自治体に提供される。また、当該電子文書に記載しているデータはNGSI v2に準拠する形式で都市OSに登録する事で、ビックデータなどととて分析可能とする




    想定システム
     本ユースケースに関係するシステムは下図の通りです。このうち、都市OSに蓄積するデータについてデータモデルを検討します。「はじめに」で出てきたエリア・データ連携基盤は、都市OSのインタフェースを司るモジュールです。



     具体的には、以下を想定します。
    • 都市OS: NGSI v2に準拠するインタフェースを有する。本システムに登録したデータは自治体・住民・および企業が参照できるオープンデータとする
    • FMシステム: 維持管理事業者は委託事業者との連携を行うシステムを有すると想定する。但し、本システムのデータは、維持管理事業者が著作権を有し、自治体と維持管理事業者との契約を終了する際には、自治体には引き渡されないと想定する。従って、契約終了後も引き続き残しておきたいデータは、都市OSにも蓄積しておく必要がある。尚、FMシステムには、各受託事業者と維持管理事業者のコミュニケーションを支える電子帳票アプリ機能があり、各受託事業者は、電子帳票アプリにて作業報告する。報告内容は、FMシステムにより必要な処理を行い、最終的に都市OSにも必要なデータが登録される
    • 維持管理BIM: 自治体や受託事業者は、維持管理事業者が提供する維持管理BIMを参照できるものとする。但し、登録情報の内容や精度は、維持管理業務に必要なレベルであるとする。自治体と維持管理事業者との契約を終了する際には、維持管理事業者はIFC形式でデータを自治体に引き渡たす事を想定する。




    データの利活用によるメリットとデータモデルに対する要件
    2022-09-10

    • 自治体は、自団体の各施設の補修状況の傾向分析などを行う事で、大規模修繕や建て替えなどの検討をデータに基づいて行う事が出来ます
    • 自治体は、他の団体の施設状況を分析する事で、より効率的な維持管理を模索したり、自団体の市民サービスレベルを客観的に把握する事が可能となります
    • 自治体は、施設管理事業者が追加測定したデータを入手することで、施設カルテの作成や推奨データセットの生成など、各種業務の効率化が図れます
    • 自治体は、維持管理BIMを活用することで、施設の案内図やパース図の作成を行う事が出来ます
    • 施設管理事業者は、他社のデータを含めて分析する事で、より効率的な提案が可能となります。民間の例では、Pタイルよりも硬質タイルの方が高価だけれど維持管理費用が安価であるためLCCが低下する、自動ドアの方が通常のとあ寄りも故障率が低くLCCが低下するなどの提案がなされています。勿論、これらの提案は住民へのサービスレベルの向上にも繋がります

    メリット享受者 ニーズカテゴリ ニーズ概要 データモデルに対する要件
    住民 公共施設の高品質な維持 自治体-施設管理事業者-受託事業者がリアルタイムなデータ連携をすることで、素早い障害対応を実現。住民は処置状況を確認出来る
    蓄積したデータの分析により、適正コストで施設管理を実現
    (ex: 安価なPタイルよりセラミックタイルの方がTCOが低いなど)

    クレーム処理状況の透明化 「空調が故障している」等の利用者からのクレームの処理状況を住民が直接確認可能
    • 発生した不具合だけを特定して処置状況を確認できる
    • データの更新日を確認できる
    • 通報者の匿名化
    • 正式名称だけ手なく、通称での通報や確認が可能であること
    施設状況や維持管理状況の透明化
    各施設の点検、保守、清掃など、市民サービスを支える活動について、住民自らが確認可能であると共に、他の自治体との比較検討がも可能
    • 自治体間のデータモデルの共通化。単に形だけが同じなのではなく、例えば障害原因の「いたずら」などの記述内容も共通化されている事が望ましい
    手厚い行政サービス体制の構築 自治体職員のデータ管理作業軽減による、フロント業務時間の確保
    自治体 不具合傾向分析 自団体の各施設の補修状況の傾向分析などを行う事で、大規模修繕や建て替えなどの検討をデータに基づいて行う
    • 不具合や点検データの蓄積
    • データ項目やデータ内容の揺れの極小化
    自治体内横断のBig Data獲得 主管課を問わず統一された形式で維持管理のデータが蓄積され、分析可能となることで、公共施設の建築などの検討時により豊富なデータを分析可能となる
    • データモデルやデータの揺れが極力小さい事
    • 文章による表記をなるべく避け、数値や列挙型項目で計算・グルーピングなどが可能である事
    高度な民間からの提案 不具合の対応状況を一覧で確認する事が可能となり、効率的な管理作業を実現できる
    • 処置が未完了の不具合だけを抽出したり、日時の範囲を指定した抽出など、多様な条件指定が可能であること
    他市と共通データ形式でデータ公開。民間事業者の施設建設や維持管理の提案の際、高度なデータ分析により高度な提案が可能
    (ex:安価なPタイルよりセラミックタイルの方がTCOが低いなど)
    • 自治体間のデータモデルの共通化。単に形だけが同じなのではなく、例えば障害原因の「いたずら」などの記述内容も共通化されている事が望ましい
    サービスの高度化 障害発生時に素早い対応を実現することで、住民の不便を早期解消。
    併せて、施設稼働率を向上
    • 特定の不具合やだけの参照や、特定の不具合の特定のPropertyだけの更新などが可能である事
    データ管理作業軽減 施設管理の作業指示/報告確認を一覧で確認
    • 処置が未完了の不具合だけを抽出したり、日時の範囲を指定した抽出など、多様な条件指定が可能であること
    施設カルテやオープンデータの作成時に元データとして活用
    • 施設カルテやす推奨データセットの項目、特に変化していく項目が含まれる事。具体的にどの様な情報が必要かは、別途検討が必要
    施設管理事業者 自治体との意思疎通効率化 作業報告などのデータをリアルタイムに都市OS上で共有することで、自治体との意思疎通を効率化
    • 建物に入居している施設だけでなく、公園などの建物を伴うとは限らない物件や、道路なども共通のデータモデルで管理できる事
    • 公園などの広い場所や学校などの部屋が多い建物は、、各自治体と合意したゾーン分けやゾーン名称を使って、住民-自治体-施設管理事業者-受託事業者間で小コミュニケーションできる事
    • 不具合の程度や優先度など、主観的になりやすい項目も具体的に定義されている事
    設備の早期保守 将来的に、設備を都市OSと繋ぐことで、利用者や自治体からのクレームを待つことなく不具合を把握
    • 設備の一つひとつにidと、設置場所などの属性が設定可能である事
    予兆保守 障害傾向を分析する事で、計画的な作業がスケジュール可能となる
    • 設備の一つひとつに型番、設置日、点検結果などの情報が蓄積される事
    施設管理提案の高度化 データ形式が共通化されオープンデータ化されている複数自治体のデータを横断分析する事により、自身の提案を高度化
    • データモデルが共通化されていること
    • 自治体や事業者間で、不具合の分類・現象・処置などの分析対象となる情報の表現が共通化されていること
    再委託事業者 作業効率化 障害発生機器の設置位置や機器情報の事前確認などが可能となる
    • 設備のPropertyに以下の情報が含まれる。尚、受託事業者にとっては、都市OSではなく維持管理BIMの参照でも構わない。その場合は、BIM上のオブジェクトのIDなどの情報が必要
      -- 設置位置、機種、メーカー、構成
    障害発生時に対象設備等の過去の障害履歴等を事前確認可能となる
    • 過去の点検や修繕の履歴情報が、設備や機器を指定して確認できること




    データ間(Entity間)の関係
    2022-09-15

     本ユースケースに関係するデータは、公共施設管理だけでなく、公共施設一般に関係する「基本情報」と公共施設管理業務の遂行に伴い発生する「施設管理情報」からなり、それぞれ以下の論理構造を持ちます。



    これらの論理構造は、データモデルの検討の過程で更に分割されたり統合されて、最終的なデータモデルとなります。

    以下、各データについての説明です。

    分類 情報 説明
    基本情報 自治体 自治体に関する情報です。自治体の名称などが掲載されます。データモデルとしては、後述する施設管理事業者や再委託事業者と同じですが、デ設定するデータのニーズが異なる可能性があるため、別に記載しています。
    所管部門 公共施設の所管課が複数あることを想定し、団体とは別の情報として整理しています。また、部門は階層化されている事が多いため、階層構造にすべきかもしれませんが、まずは階層化しない前提で設計します
    施設 公共施設に関する情報です。公共施設はひとつの建物を占有する場合、複合施設の様に一部を占有する場合、民間の建物の一部を賃借する場合などがあり、土地や建物と分離してあります。また、公園の様に建物を伴うとは限らないものも施設と考えました。土地や建物と実際にデータモデルを分離すべきかどうかは、ニーズに照らして議論が必要です
    土地 公共施設が入居する建物が建築されている土地に関する情報です。少なくとも、住所の情報が保持されます。
    建物 公共施設が入居する建物の情報です。公共施設では多くの場合建物の名称や通称があるため、その名称が保持されます。尚、大きな建物は複数の建物から構成される場合があり、その場合は階層構造になりますが、どの様に表現すべきかは議論があり得ると考えます。例えば、○○小学校は体育館と炊事室と校舎から構成されるなどです。まずは、建物が複数の建物から構成されるようなデータモデルにしませが、必要であれば拡張が必要です。
    施設管理情報 施設管理事業者 施設管理事業者に関する情報です。施設管理事業者は自治体自身であっても構いませんが、ここでは別の団体として整理しています。コールセンタの連絡先などの情報が保持されます。データモデルととしては、前記との団体と同じです。
    設備/デバイス 空調機など点検や補修の対象となるデバイスです。障害通報時には型番や型式や設置時期などの情報は記載されませんので、本情報と突き合わせることで、分析が可能となります。
    障害/通報 利用者から何らかの不具合の通知があったときに登録される情報です。緊急度や障害現象などが記載される事を想定しています。定期点検や清掃などの作業中に検出した不具合も、利用者からの通知と同様に登録されます。
    レポート 障害などの通知に対する、受託事業者の処置内容や結果を記載します。ひとつの障害に対し複数のレポート(暫定処置と最終処置など)があり得るため、障害・通報と分離しています。また、レポートは障害だけでなく、清掃や定期点検でも発生するはずであり、このレポートが更に細分化されるなどの可能性があります
    再委託事業者 再委託事業者の法人情報です。後で分析するために、本人名や法人番号などを保持します。これも、データモデルは、前記の団体や施設管理事業者と同じですが、図では別に表現しています。
    担当事業所 再委託事業者の事業所が複数ある場合や受託事業者の本社が域外にあり、担当する近隣の事業所が分かれている場合などを想定し、受託事業者とは分離してあります。分離の必要性については議論が必要だと思われます。




    策定の進め方
    2022-09-15

     本ユースケースでは、以下の様なプロセスでデータモデルを策定します。

    • GIFのコアデータモデルに類似するデータモデルが存在するものは、コアデータモデルから項目抽出
      -- コアデータモデル: 法人・事業所・施設・土地・建物・設備からの抽出を想定
    • NGSi v2でのデータモデルの規約に則って書き換える。具体的には、idの形式をNGSI-LDの規定に合致させる、必須Propertyであるtypeを一律に追加、項目名(attribute name)は英語名を小文字で始まるキャメルケースに変更するなど
    • モデル名、項目名、データ型については、schema.orgやSmart Data Modelsでとの共通化を検討する。例えば、××nameはnameに統一するなど
    • 入れ子になっているデータモデルはデータを分離し、Relationshipによる参照関係に変換する。例えば、コアデータモデルの「建物」では、「関連建物」という項目があるが、この項目は他の建物の情報をそのままそっくりコピーして格納するとなっている。この様な場合、データのメンテナンス上不合理なので、建物のEntityを別々に2件格納し、idで紐づける事とする。尚、住所など入れ子になっている事が合理的な場合はStructuredValueとして展開する。
    • 項目値が「有」「無」などの二値の値だけをもつ文字列は、Booleanに変更する
    • 将来のNGSI-LDへの移行のため、データモデルのIRIも掲載する
    • 施設管理事業者の作業レポートから、データ項目を追加
      -- クレームに対するヒアリング報告書や点検報告書などを想定
    • NGSI V2に準拠したNormalizaed形式とkeyValue形式で例を掲載する
    • 「期待するメリット」を実現するためにデータ項目が不足しないか、個々のメリット毎に確認
    • 自治体および施設管理事業者がデータを提供可能か検討
    • 住所や座標などの共通する項目をくくりだし、データモデルの共通バーツとして整理
    • データモデルを定義
    • 不具合の現象など、ビックデータなどの分析時に共通化されていて欲しいデータの表現を列挙型メンバとして定義
    • これらの共通仕様を公開


    Coppell Technologies