智慧城市顶层设计范例：以数字家庭区块为例-P02

智慧城市顶层设计范例：以数字家庭区块为例-P02

 

[-1-]   [-2-]
  [-3-]

 

4. 顶层设计方法与范例：以<数字家庭>为例

       在上一节里，只说明了如何心怀SoS思维和视角，来看数字家庭业务区块的合作关系，进而得出顶层设计蓝图的三项观点：业务观点、系统观点和通信观点。但是，尚未细说这三项观点的内涵。在本节里，就来介绍这三项观点的内涵。由于数字家庭业务区块的顶层设计内涵丰富，于此专注于其要点，并举例说明之；让你熟悉这三项观点的核心内涵，以及规划的顺序。

4.1  规划<业务观点>

       兹复习基本流程，首先心怀SoS思维和视角，看数字家庭业务区块的组织层SoS合作关系，进而得出业务观点。如下图：



图-12  基于 {EA模式+SoS视角} 规划出业务观点

4.2  对业务单元进行分类(Classification)

       在上一节已经介绍过，依据EA(Enterprise Architecture)架构规范，顶层设计(蓝图)里，必然会提供一项重要图示，就是：业务单元(Operational Node，简称OPN)和系统单元(System Node，简称SYN)。现在，就来建立业务单元(OPN)的分类图。首先分析出数字家庭业务区块里含盖那些OPN。把OPN区分为<移动>和<非移动>两类；然后，非移动OPN再细分为<城市>、<家庭>、<企业>和<机构>等不同类型。同样地，再将移动OPN细分为<Person>、<Vehicle>等不同类型。于是，得出业务单元的分类图，如下：



图-13 业务单元(OPN)的分类 
       上图只是举例说明而已，实际顶层架构里的OPN种类应会比上图复杂多了。

 4.3  规划业务单元的合作(Collaboration)

       上图表达了OPN之间的分类关系，但没有表达出它们的合作关系。于是，就采取前面介绍过的SoS视角，来看这些OPN之间的合作关系。于此，就拿<家庭OPN>、<个人OPN>、<医院OPN>、<公交车OPN>和<小区OPN>之间的合作来举例说明之。如下图所示：



图-14  数字家庭(业务区块)的OPN层SoS
       在此图里，尚未表达出合作的详细情境，包括：
该进行那些合作?
各项合作的任务是什么?
各项合作需要哪些OPN参与?
谁主导这项合作?
       现在，就来举三个合作任务做为范例，来说明之。这三个任务是：
Ex-1. 家里自我健康检测
Ex-2. 家庭健康信息推送
Ex-3. 移动查询健康分析
       接着，就来细说这三个合作任务的情境，包括合作的任务(Task)，每项任务就是一个事件(Event)，一个事件常常需要多个OPN相互合作，而且事件发生有其时间上的先后顺序。请看详细的描述如下：

4.3.1   规划OPN合作任务

       刚才提出了三个任务来做为范例，现在来说明这些任务的详细内容；如下：
举例任务(一)

合作ID：Ex-1

合作名称：家里自我健康检测
任务[b]：[/b]各家庭成员(个人)自己做健康检测，其检测结果数据传送到医院的健康服务中心，进行检测数据的解析。
合作OPNs：智能家庭、医院和个人
主导者：智能家庭
举例任务(二)

合作ID：Ex-2

合作名称：家庭健康信息推送
任务：智能家庭定时从医院取得健康检测的解析报告，并主动推送给各家庭成员(个人)
合作OPNs：智能家庭、医院和个人
主导者：智能家庭
举例任务(三)

合作ID：Ex-3

合作名称：移动查询健康分析
任务[b]：[/b]家庭成员(个人)随时透过3G上网访问医院的健康服务中心，查询个人或家人的最近健康趋势分析
合作OPNs：个人和医院
主导者：个人
       兹以图形来表达这三项合作任务，以及任务(事件)的先后顺序，如下图所示：



图-15  OPN层的三项合作任务，及其先后顺序
       此图表达出三项任务规划，而且有时间的先后顺序。第1项合作任务是：从个人身上的检测仪取得检测结果，然后将其检测数据传送到医院的健康服务中心，以便解析检测数据。此任务是由<家庭OPN>主导，带领<个人OPN>和<医院OPN>来合作完成。再看第2项合作任务，也是由<家庭OPN>主导，带领<个人OPN>和<医院OPN>来合作完成。至于第3项合作任务则由<个人OPN>主导，带领<医院OPN>来合作完成的。

4.3.2   规划任务执行时，OPN之间的信息交换(Message Exchange)

       主导者OPN触发任务事件。主导者为了完成任务目标，指挥相关的OPN去执行活动，并提供相关信息。于是，顶层设计里需要规划OPN之间的信息交换的属性和限制等规范。这些信息交换规范，将成为系统层SYN之间数据交换接口(Interface)设计的需求，以及通信层网络宽带的负荷等性能条件。这些接口和通信条件，也将决定各OPN之间是否能有效进行信息分享的决策依据。所以，顶层设计里需要对这信息交换需求做很明确的规范。兹以图形表达如下：
Ex-1  举例任务

Ex-1. “家里自我健康检测”任务的信息交换



图-16  合作任务Ex-1的信息交换图
       除了上图的信息流动关系之外，在顶层设计文件里，还要对信息的大小(Size)、传送频率等属性详加叙述。还有，触发这些信息流动的事件，其发生的顺序也非常重要，其攸关合作任务能否正确执行的业务质量和可靠度。所以，加以图示如下：



图-17  合作任务Ex-1的事件发生顺序图
Ex-2  举例任务

Ex-2. “家庭健康信息推送”任务的信息交换



图-18   合作任务Ex-2的信息交换图
       接着，以图形表达这些信息流动的触发事件，及其发生的时间顺序，如下图：



图-19  合作任务Ex-2的事件发生顺序图 
Ex-3  举例任务

Ex-3. “移动查询健康(趋势)分析”任务的信息交换



图-20  合作任务Ex-3的信息交换图
       接着，以图形表达这些信息流动的触发事件，及其发生的时间顺序，如下图：



图-21  合作任务Ex-3的事件发生顺序图

4.4  规划<系统观点>

       前面已经提到过，业务层SoS里的OPN之间信息交换，大多会委托SYN来实现。例如，<家庭OPN>向<医院OPN>索取健康检测解析图表的信息交换，其实现方式是家人藉由<智能电视SYN>经由互联网向医院里的<云平台SYN>进行查询的。所以，系统层SoS是要去实践业务层SoS里OPN之间的信息交换。愈深度信息化的业务区块，其OPN之间的信息交换，愈是仰赖SYN来实现；对系统SoS的功能需求愈多，必要的投资也愈多。当这样的系统层SoS变得复杂了，顶层设计里的系统架构(观点)和通信架构(观点)内涵也会愈复杂而多样化。
       其中，OPN之间通信的规划是需求，而SYN之间的信息交换，则是来实践该需求。所以，系统架构的必备职责是：支撑业务架构的任务。系统架构的形式(Form)与业务架构的形式可以独立，但是在功能(Function)、责任(Responsibility)上必须紧密相依。两者结起来，才成为一个融洽和谐的顶层设计。如下图所示：



图-22  基于 {EA模式+SoS视角} 规划出系统观点
       显而易见的，智慧城市对信息化的依赖将会日益加深，使得整个城市的顶层设计的业务架构和系统架构环节的内涵也日益复杂而多样化。当顶层设计的系统SoS部份愈复杂时，往下的中层设计(Middle-level Design)内涵的复杂性更会急速升高。因此，笔者也建议采用”EIT造形”的组装模式来大幅降低中层设计的复杂性；同时也大幅简化更下面的实践层设计，因而减轻实践阶段的负担。

4.5  对系统单元(SYN)进行分类

       分类图是架构设计最基础的文件，就如同生物学家将自然界事物进行分门别类一样，是人们理解和规划事物的基础。俗语说：物以类聚。同类型的事物有共通的属性、接口、零件或行为等，人们可以对它们采取类似的描述、制造或管理模式；它们之间常有共同接口，所以可以互相替换。以上说明了分类图在架构设计上，一直扮演非常基础的角色。一个OPN里常包含一个或多个SYN。而 SYN之间会透过通信网路来相互传递信息。两个OPN之间透过各自内含的SYN来交换信息或数据。SYN可分为：
有IP的SYN(简称IP SYN)。
非IP的SYN (又称Sensor SYN)。
然后，上述两者，都可再细分为：移动与非移动两种类。如下图所示：



图-23  系统单元(SYN)的分类图

4.6  规划系统单元(SYN)的合作

       依据前面所述的鸡蛋比喻，OPN是鸡蛋，而SYN是蛋黄。在上述的图-14里，可以看到我们所举例的5个OPN(即鸡蛋)：<家庭>、<个人>、<医院>、<公交车>和<小区>。接下来，从鸡蛋里找出蛋黄(即SYN)，可找出许多SYN，然后规划其初步的连结(Link)关系。如下图所示：



图-24  数字家庭(业务区块)的OPN层SoS
       目前找到的SYN及其连结关系，都是初步的起点而已，后续进入到更细节的规划时，可能会发现有需要规划新的SYN，或新的连结关系；届时会再回头来修正上图。这样的EA模式，通称为迭代式(Iterative)模式。也请留意，一个OPN可能内含多个SYN，例如医院OPN内可规划两个SYN：<云平台SYN>和<检测数据解析SYN>。如下图：



图-25  医院OPN里含有多个SYN和人员的角色
       <云SYN>扮演负责对外信息交换的接口(Interface)，并且将外界(如家庭里的<智能电视SYN>)传来的健康检测数据，转送给<解析SYN>去做解析判读的工作。除了SYN之外，OPN内部也常常有人员来使用SYN。一个人可以扮演医生角色(Role)，也可以扮演护士角色。一旦返回家中，则又扮演另一个角色：家人。再如，家庭里也可以规划多的SYN，例如<电视SYN>和<网关SYN>等，如下图所示：



图-26  家庭OPN里含有多个SYN和人员的角色
       也许你会问到，一个OPN里该有几个SYN呢? 请留意，所谓顶层设计，就是一种迎接未来、创造未来一种规划(投资计划)，所以要视这数字家庭业务区块的业务层SoS将提供那些业务(或服务)而定了。当未来的某一天，业务层SoS需要提供新业务时，可能就需要在家庭OPN里规划一个新的SYN。例如，随着NFC通信协议的逐渐普及，家庭的门口，就可新增一个<NFC Tag SYN>，让家人返家时，拿手机碰触一下<NFC Tag
SYN>，就可以自动开门，并将手机设定为静音等等。基于这样的新需求，上图的<家庭OPN>就会演化(增添一个新SYN)成长，如下图：



图-27  家庭OPN里的增添了新SYN
       再如，在外的家人(个人OPN)也可以携带多个SYN；例如，可移植性的健康检测仪器(即<健康检测SYN>)和<手机SYN>等等，如下图所示：



图-28  个人OPN里含有多个SYN和人员的角色 

4.7  规划SYN之间的合作及其数据交换

       前面说过了，OPN之间通信的规划是需求，而SYN之间的合作及数据交换，则是来实践该需求。所以，系统架构的必备职责是：支撑业务架构的任务。前面，我们举了三个合作任务做为范例。这三个任务是：
Ex-1. 家里自我健康检测
Ex-2. 家庭健康信息推送
Ex-3. 移动查询健康分析
       接下来，就来说明如何规划SYN的合作，来支撑这三个OPN层的合作任务。

4.7.1   针对OPN层合作任务：Ex-1

       兹复习OPN层的Ex-1任务：”家里自我健康检测”，如下图：



图-29  OPN层合作任务Ex-1的信息交换图(与上图-16相同)
       为了支撑上图的任务Ex-1，就来规划SYN层的两项合作任务：
任务Sx-1.1：规划医院对外(家庭)的合作及数据交换
任务Sx-1.2：规划医院内部SYN之间的合作及数据交换。
       兹详细说明如下：
1) 合作任务Sx-1.1：医院对外的合作及数据交换。详细如下图：



图-30  SYN层合作任务Sx-1.1的数据交换图
       此图里的合作及数据交换，就是要支撑OPN层任务Ex-1的(医院之外)信息交换。个人身上的<健康检验仪SYN>就定位之后，由<智能TV/STB SYN>去启动它(仪器)，开始检测和接收数据，并将检测的结果数据传送到医院的<云平台SYN>，再转给医院里的<解析SYN>去做解析任务(如下图-31所示)。
2) 合作任务Sx-1.2：医院内部SYN之间的合作及数据交换。详细如下图：



图-31  SYN层合作任务Sx-1.2的数据交换图
       这图里的合作及数据交换，就是要支撑OPN层任务Ex-1的(医院内部)信息交换。

4.7.2   针对OPN层合作任务：Ex-2

       兹复习OPN层的Ex-2任务：” 家庭健康信息推送”，如下图：



图-32  OPN层合作任务Ex-2的信息交换图(与上图-18相同)
       为了支撑上图的任务Ex-2，就来规划SYN层的一项合作任务，如下：
合作任务Sx-2.0：家庭对外的合作及数据交换。详细如下图：



图-33  SYN层合作任务Sx-2.0的数据交换图
       此图里的合作及数据交换，就是要支撑OPN层任务Ex-2的(家庭之外)信息交换。由<智能TV/STB SYN>依据预先设定的时间表，主动向医院的<云平台SYN>查询最近的检测数据分析报告，再推送到个人身上的<手机SYN>里。

4.7.3   针对OPN层合作任务：Ex-3

       兹复习OPN层的Ex-3任务：”移动查询健康分析”，如下图：



图-34  OPN层合作任务Ex-3的信息交换图(与上图-20相同)
       为了支撑上图的任务Ex-3，就来规划SYN层的一项合作任务，如下：
合作任务Sx-3.0：医院对外(个人)的合作及数据交换。详细如下图：



图-35  SYN层合作任务Sx-3.0的数据交换图
       此图里的合作及数据交换，就是要支撑OPN层任务Ex-3的信息交换。由个人身上的<手机SYN>主动向医院的<云平台SYN>查询个人最新的健康趋势分析图。
( 請繼續閱讀… )
[-1-]   [-2-]
  [-3-]