简介：西门子 Desigo CC 用户界面中文培训手册（BA-CN）面向楼宇自动化系统的工程调试、集成与运维人员，也适合刚接触该平台的学习者，用于快速建立对图形界面与工作流操作的整体认识。内容按模块展开：主要应用程序、工作流驱动的窗格概念、屏幕顶部的摘要栏（事件灯、过滤器、操作员菜单与语音警报）、事件通知与快速处理、调查处理、辅助处理流程，以及系统浏览器中的应用程序视图、管理视图和自定义视图，另含最近浏览窗格、文本查看器、关联应用程序和操作窗格中常用命令与确认操作。整份资料为 1 个 PDF 文件，压缩包约 2.41MB，排版紧凑，便于随查随用。目前已有 1581 人学习，读者可对照章节目标逐项练习界面导航、事件查看与视图定制，为现场调试和日常运维打下操作基础。

1. 用户界面不是皮肤：先看这张四区一栏的地图

楼宇自控平台的用户界面，第一眼看上去像被切成几块的屏幕：顶部一条摘要栏，左侧一棵系统浏览器树，中间一大片主窗格，右下角一小块操作窗格，四块区域各管一摊，窗口层层叠叠的情况被彻底去掉。很多复习的人把它当成“皮肤”，以为记住了按钮位置就掌握了，真正上手才发现卡住的从来不是位置，而是判断：这个对象该在应用程序视图还是管理视图里找，现在处于编辑模式还是操作模式，事件灯亮了三层信息该先看哪一层。这套用户界面的设计思路是让工程、操作、报警三条链路同时在线，谁也别遮谁。适合两类人：正在系统学楼宇自控上位机的人，需要一张完整的功能地图；已经在现场值班或调试、想回头把零散经验串成体系的人。

2. 布局与工作流：四区一栏怎么切、为什么这么切

先给结论：这套用户界面的布局不是按“功能菜单”组织的，而是按“工作流”组织的。传统上位机喜欢用重叠窗口，开一个报警窗口就得把后面的图形页挡住；这套界面改成窗格并列，同一时刻屏幕上的每一块都有明确职责，谁需要更多空间谁就占主窗格，其余退到侧边。理解这条原则之后，后面所有“为什么这个按钮在这儿”的疑问都能自己推出来。

2.1 四个固定区域的分工

这四块的层级关系值得多说一句。摘要栏是全局层，任何时候都在，它管的是“系统整体状态”；系统浏览器是导航层，决定你看到什么；主窗格是内容层，随导航变化；操作窗格是动作层，只对当前选中对象生效。四层各司其职，越权使用就会出问题，比如拿主窗格的右键菜单去改工程参数，多半是因为没意识到自己还在操作模式里。

工作流概念里还有一组词容易混：主要监控与次要监控。它们对应的不是两个窗口，而是同一块主窗格的两种占用方式——主监控占据主窗格处理需要持续关注的内容，次要监控退到侧边，保持可见但不抢焦点。操作摘要与警报摘要则是把“正在做什么”和“出了什么事”分成两条信息流，分别喂给不同的窗格。

2.2 无重叠窗口带来的三个实际收益

第一是上下文不丢。处理报警时图形页还在，确认完一条事件抬头就能核对现场值，不用来回切窗口。第二是多语种支持做得更彻底，因为文本长度变化不会撑破固定的窗格结构，切换语言后布局不会乱成一团。第三是屏幕利用率稳定，投影、远程桌面、双屏这些场景下，窗格比例不会因为窗口浮动而反复调整。

代价也有：窗格划分是固定的，习惯了自由拖窗口的人一开始会觉得束手束脚。复习时把这当成设计取舍记住就行，别把它当成缺陷去背。

2.3 主要应用程序清单与它们的归属

这张表的作用是建立归属感。复习到某个功能想不起在哪，先问它属于“管对象”“看数据”还是“做动作”，三类分别落在不同视图和不同窗格里，比死记菜单路径靠谱得多。

2.4 在线工程：本地与 Web 两条入口

在线工程是这套用户界面的一个关键能力，也是复习里最容易只记住名词、说不清边界的地方。它的几个特征值得逐条拆开：

本地工程与 Web 工程并存，意味着同一套工程数据可以从工作站打开，也可以从浏览器入口进入；在线工程（未编译）表示改动还在草稿状态，没走编译这一步，此时看到的效果和最终运行效果可能不一致；拖放、复制粘贴、搜索替换属于批量编辑手段，用来对付成百上千个命名相似的点位；库则是把可复用的对象模板沉淀下来，避免每个项目从零搭。

这里最容易踩的坑是把“在线改完”当成“已经生效”。在线工程的未编译状态是一个明确的中间态，改完到生效之间还有一步，复习时把它当成一条独立的检查项记住，比记住某个按钮的位置有用得多。

3. 摘要栏与事件处理：一条报警要走完的三层

摘要栏是整套用户界面的接入点，位置在屏幕最上方，内容看着不多，但它同时承担了状态展示、导航入口和会话管理三件事。复习这一章的目标很明确：拿到一条报警，知道它在哪一层被看见、在哪一层被确认、在哪一层被追溯。

3.1 摘要栏上到底放了什么

从左到右大致是这几类元素：事件灯、菜单、过滤器、系统信息、语音报警，另外还有一个系统完整性指示器。逐个说清楚用途：

事件灯是分类视图，不是简单的“有报警就变红”。不同颜色和状态对应不同类别与等级，它的作用是让你在没打开任何列表的情况下判断“现在需不需要立刻动手”。

过滤器决定事件灯和事件列表里显示哪些事件。值班场景下按区域过滤、按等级过滤是常规操作，但过滤器是有状态的，切换班次时忘了复位，下一班就会以为“今天很太平”。

系统信息与系统完整性指示器反映的是平台自身的健康状况，不是现场设备状态。这条区分很重要：现场一切正常但完整性指示异常，说明问题在服务器侧或数据链路侧，别一头扎进现场查点位。

语音报警是给无人值守场景准备的，静音是一个动作而不是关闭功能，复习时留意这个差别。

3.2 菜单逐项对照

最后一行是这一章最值钱的一条。退出关闭的只是图形界面程序，后台服务继续在服务器上跑，采集、报警、记录都不停。很多人第一次遇到“我明明退出了怎么还在报警”，答案就在这里。

用户文档那一项也值得单独提一句：技术文档库规模不小，千页量级，但能看到哪些内容取决于装了哪些扩展模块。复习时如果发现某份文档打不开，先怀疑模块没装，而不是文档缺失。

3.3 事件通知的三层结构

第一层是摘要栏的事件灯，给的是分类概览；第二层是事件详细信息栏，只显示一到两条需要立即注意的重大事件；第三层是事件列表，列出所有未处理事件及其详细信息。再往下还有事件日志和活动日志，负责追溯。

这个三层结构的用意是控制注意力。值班的人先扫事件灯判断整体，再看详细信息栏确认最紧急的一两条，需要处理时才展开完整列表。反过来做——一上来就打开全量列表——在事件密集的时候会被淹没。

复习时把这三层和“确认”这个动作对上号：确认发生在列表层，概览层只负责提示，追溯层只负责记录。三层混用就会出现“我确认了怎么还亮着”的困惑。

3.4 三种处理程序的判定逻辑

材料里给了三个名字：快速处理、调查处理、辅助处理。名字好记，难的是判断什么时候用哪个。下面这段是抽象出来的判定逻辑，不是平台内置脚本，用来帮你在复习时把边界想清楚：

def pick_handling(event, repeat_count, need_trend, cross_system, has_procedure): # 快速处理：原因明确、影响单点、处置动作是确定的一两步 if event.cause_known and event.scope == "single_point": return "快速处理" # 调查处理：短时间内重复出现，或必须调趋势/历史数据才能定性 if repeat_count >= 3 or need_trend: return "调查处理" # 辅助处理：跨系统联动，或现场有既定预案要按步骤走 if cross_system or has_procedure: return "辅助处理" return "快速处理"

几个参数的含义值得说透。cause_known指报警原因是否已经明确，比如某台设备检修中触发的状态报警；repeat_count是同类事件在窗口期内的重复次数，重复本身就是信号，单次抖动和反复抖动要分开对待；need_trend表示必须拉趋势才能判断是传感器漂移还是负荷真变了；cross_system指事件影响横跨多个子系统，比如冷源异常牵连到末端；has_procedure指现场有书面预案。

判定顺序也有讲究：先排除单点已知原因，再判断是否需要数据佐证，最后才看是否走预案。顺序反了会把简单问题复杂化，一个明确原因的滤网报警被拉去做趋势分析，纯属浪费。

3.5 报警等级与优先级的映射

摘要栏里的报警级别映射到楼宇自控领域通用的报警优先级体系上。这件事的意义在于：不同厂商设备接入后，各自的报警等级命名五花八门，映射到统一优先级之后，事件灯的颜色、详细信息栏的取舍、语音报警的触发才有统一依据。

复习时记住映射这个动作本身比记住具体数值更重要。现场调试阶段如果发现某类报警“明明很重要却不显眼”，八成是映射关系没配对，而不是界面坏了。相关细节在事件管理部分展开，这里只要建立起“等级不是设备自己说了算，是映射出来的”这个认知。

4. 系统浏览器与窗格导航：视图选错，后面全错

系统浏览器负责显示应用程序和数据库对象，它左侧那棵树决定了主窗格里能看到什么。这一章的核心只有一句话：视图不是显示偏好，是作用域。选错视图，你会在错误的地方找对象，然后得出“这个点位不存在”的结论。

4.1 三个视图的分工

应用程序视图里也会出现工程类应用对象，图形、趋势、调度、报告、视频都在这一层打开。这一点常被误解成“应用程序视图只能操作不能工程”，实际上它的定位是“工作流入口”，工程对象的日常打开也走这里。

管理视图的价值在拓扑。设备挂在哪台控制器下、控制器属于哪个站、层级关系对不对，这些只有在管理视图里才看得清。调试期在应用程序视图里翻半天找不到某个点的归属，切到管理视图往往一眼就明白。

自定义视图的可选性值得强调。它能为不同用户或用户组分别设置，也能按特定学科或特定建筑组织。这意味着同一个平台，暖通班组看到的是冷站、空调机组、通风，电气班组看到的是配电、照明，互不干扰。复习时把这条和权限概念绑在一起记，后面排查“为什么他看得到我看不到”会快很多。

4.2 自定义视图的本质是重组

很多人以为自定义视图是新建一套对象，其实它只是把两个默认视图里的对象挑出来重新编目。抽象出来的结构大致是这样：

// 自定义视图树的抽象结构示意，非平台真实文件格式 { name: "某建筑-暖通专业", scope: "user_view", children: [ // 从管理视图挑拓扑节点 { label: "冷站", type: "folder", target: "management_view/冷源系统" }, // 从应用程序视图挑工作流页面 { label: "空调机组", type: "folder", target: "application_view/图形页" }, // 挑事件列表并带过滤条件 { label: "未处理报警", type: "folder", target: "event_list?filter=unhandled" } ] }

三个字段说明白就够了。scope标明这是用户视图而不是默认视图，children是树的内容，target指向真正的对象位置。关键在target：它指向的可能在管理视图，也可能在应用程序视图，甚至是一个带过滤条件的事件列表。这正是自定义视图的价值——把“我每天要看的十几个地方”压成一棵树。

也正因为它是引用而非复制，原对象改名、移动、删除之后，自定义视图里的入口会跟着失效。复习时把这条当成维护提醒：改完工程结构，回头检查一遍自定义视图的入口是否还有效。

4.3 最近浏览窗格与它的 20 条上限

最近浏览窗格解决的是“刚才那个页面在哪”的问题，显示为缩略图或描述，最多保留 20 项，最近访问的排在最上面。

20 这个上限是需要记住的硬参数。它在日常值班里够用，在调试期就不够——一天下来打开几十个页面，早上看过的早被挤出去了。所以调试期的正确做法不是依赖最近浏览，而是把高频页面挂进自定义视图。这也是两个功能的分界线：最近浏览是临时回退，自定义视图是长期入口。

缩略图与描述的切换也值得留意。图形页用缩略图一眼能认，纯参数页用描述更清楚，混着用反而降低识别效率。

4.4 主窗格里的文本查看器

选中对象后主窗格会显示文本查看器，用简单网格呈现路径、名称、值、最高状态和类型五项，并且会连带显示选中对象的子对象。

这五项里，路径和最高状态是最容易被低估的。路径告诉你对象在树里的确切位置，排查“这个点到底挂在哪”时比一层层展开树快得多；最高状态是把对象自身及其子对象里最严重的状态提上来，一个文件夹展开看着都正常，最高状态却报警，说明问题在某个子对象上，顺着往下找就行。

文本查看器的定位是“快速核对”，不是“深度分析”。要看历史走趋势，要看联动走图形，别指望在这张网格里做诊断。

4.5 操作窗格与扩展操作选项卡

操作窗格提供主窗格之外的扩展信息，把最常用的任务放在手边：命令、发布、确认、服务中/中断服务。扩展操作选项卡再补充额外信息和功能。

“服务中/中断服务”这两个状态词值得单独说。它们不是简单的开关，而是把设备从自动逻辑里临时摘出来的手段，用于检修和维护。用完之后忘记恢复，设备就一直在服务中状态，自动逻辑不接管，现场表现是“怎么调都不动作”。这是运维里非常经典的一类问题，复习时把它和后面的易错点连起来看。

操作窗格的设计意图是减少跳转：选中对象之后，八成动作就在右下角，不用回主菜单找。习惯了这条，操作效率会明显不一样。

4.6 编辑模式与操作模式

管理单元里有两种模式：编辑模式和操作模式。这是整套用户界面里最需要在复习阶段分清的一对概念。

操作模式面向日常运行，能看、能确认、能发命令，但不改结构；编辑模式面向工程配置，能改属性、能加对象、能调参数，但此时的操作行为不代表真实运行状态。两者的关系不是权限高低，而是语境不同。

现场最常见的翻车是：在编辑模式下试命令，发现设备没反应，以为通讯故障，其实是模式不对；或者改完参数忘了切回操作模式，第二天值班的人看着一堆可编辑字段不敢动。这条留到下一章细说。

5. 易错点排查：五处最容易在实操里翻车的地方

前面四章把地图、区域、事件、导航都过了一遍，这一章专门收口到易错点。梳理下来会发现，这些坑的共同特征是“当时不觉得错，过两天才发作”，所以按“易漏点 → 为什么漏 → 怎么补”三段来写，方便对照自己的操作习惯。

5.1 界面认知层面的三个易漏点

易漏点一：把“退出”当成停机。为什么漏：退出菜单的字面意思太强，加上界面确实消失了，直觉上就是“关掉了”。实际退出只关闭图形界面程序，后台服务仍在服务器上运行，采集、报警、记录全部照旧。更麻烦的是语音报警和远程通知依然会发，人却不在界面前，出了事件没人接。 怎么补：把“退出”重新命名为“关闭界面”，在交接班流程里明确写一条——退出前确认报警接收人已经切换到下一班。判断系统是否还在运行，看的是服务状态和系统完整性指示器，不是看界面在不在。

易漏点二：在错误的视图里找对象。为什么漏：两个默认视图都默认安装，打开就能用，树的样子也相似，很容易一直在自己习惯的那个里翻。应用程序视图偏向工作流入口，管理视图偏向系统拓扑，一个点位在管理视图里挂在某控制器下，在应用程序视图里可能只是一张图形页上的一个可点击元素，两边看到的“同一个东西”形态完全不同。 怎么补：建立一条固定的判断顺序——先问“我要看的是它挂在哪，还是它怎么用”。看归属去管理视图，看使用去应用程序视图，两边都没有再去自定义视图确认是不是被筛掉了。搜索替换这类批量操作也要注意作用域，改之前先确认当前视图覆盖了哪些对象。

易漏点三：只盯事件灯，漏掉下面两层。为什么漏：事件灯最显眼，扫一眼有颜色就以为掌握了全局。但事件灯给的是分类概览，详细信息栏只挑一到两条最紧急的，完整信息在事件列表和日志里。只停在第一层，容易漏掉“同类事件反复出现”这种只有列表才看得出的模式。 怎么补：形成固定的下钻动作——事件灯看类别，详细信息栏看最紧急，事件列表看总量和重复度。值班交接时把事件列表的未处理项过一遍，比看灯可靠。追溯类的判断走日志，别指望在灯上找因果。

5.2 操作与工程层面的两个易漏点

易漏点四：编辑模式与操作模式混着用。为什么漏：两种模式在界面上没有强烈的视觉阻断，字段能不能改、命令发出去有没有真实效果，全靠自己记得当前在哪个模式。调试期长时间待在编辑模式，顺手点了个命令，看到没反应就开始查通讯，方向从一开始就错了。 怎么补：把模式当成一个显式状态来管理——进入编辑模式前先想清楚这次要改什么，改完立刻切回操作模式，并把“确认当前模式”写进任何一次现场操作的准备清单。多人协作时更容易出问题，活动任务列表里能看到当前会话，交接时对一眼比口头确认可靠。

易漏点五：自定义视图与最近浏览的边界搞混。为什么漏：两个功能都解决“快速到达”，用起来感觉差不多。但最近浏览最多 20 项，是被动记录，会被后来者挤掉；自定义视图是主动编目，长期有效。调试期依赖最近浏览，一天下来发现早上看过的页面全没了，只好重新一层层点开。 怎么补：分工明确——临时回退用最近浏览，高频入口进自定义视图。另外记住自定义视图是按用户或用户组设置的，换人看到的内容可能不同，排查“为什么他那边没有这一项”时先看视图归属，再看权限。工程结构改动之后，回头验证一遍自定义视图里的入口是否还有效，这一步很容易被跳过。

这五条串起来其实就是一条主线：所有的坑都出在“状态”上——运行状态、视图状态、模式状态、入口状态。把状态显式化，比记住更多按钮有用。

6. 复习清单：一套可以照着走一遍的自查路径

复习到这儿，如果只是把前面几章重读一遍，效率不高。更有效的做法是拿一张清单去自查，每一条都问自己“能不能不看资料说出来”，说不出来的再回对应章节补。下面这张表是按“能不能复现”组织的，不是按章节顺序。

清单走完一遍，通常会暴露两类问题。一类是“名词记得、边界说不清”，比如知道有应用程序视图和管理视图，但说不清一个点位在两边分别长什么样；另一类是“知道该做什么、不知道什么时候做”，比如知道要切回操作模式，但没形成固定的触发点。前一类靠回看表格补，后一类得靠流程补——把动作挂到一个明确的时机上，比如“改完参数立刻切回”比“记得切回”可靠得多。

还有一个自查技巧值得试：找一张现场的图形页，从摘要栏的一条报警出发，完整走一遍路径——看事件灯判断类别，进事件列表确认，选中对象看文本查看器的最高状态，进操作窗格发命令，最后检查当前模式。这一趟走顺了，说明地图真的在你脑子里；哪一步卡住，那一步就是你的薄弱环节，比从头再读一遍精准得多。

我自己吃过一次亏：调试期一直在编辑模式里试命令，设备没反应，顺着通讯链路查了大半天，最后发现只是模式没切回来。从那以后我每次动任何参数之前都强制走一遍“看模式、看视图、看当前会话”这三步，哪怕明知道没问题也走，图的就是不给自己留后悔药的机会。希望帮到你。

这份笔记对应的完整用户界面章节资料已经整理好了，需要对照原文章节逐页复习的，可以直接取用。

本文还有配套的精品资源，点击获取