简介：这份西门子Desigo CC工程配置手册面向楼宇自动化工程师、系统管理员及项目实施人员，聚焦系统管理控制台中的项目落地与日常运维，帮助读者理清从历史数据库创建、项目实例化到配置备份的关键流程。压缩包内仅有1个PDF文件，大小约2.23MB，正文围绕历史数据库的扫描链接、容量与恢复参数设置，恢复项目模板、恢复项目备份和创建新项目三种实例化方式，事件处理行为与项目文件夹共享权限配置，以及项目和历史数据库的备份恢复展开，并说明预配置模板在缩短工程时间、降低出错风险方面的作用。已有559人学习，适合需要按手册完成项目配置、排查数据库链接与项目启动问题的技术人员对照查阅，也可作为实施前的流程梳理和操作要点参考。

1. 从一台“装完就没人敢动”的服务器说起

第一次在一台刚装完 Desigo CC 的服务器上打开系统管理控制台（SMC），大部分人会在同一个地方卡住：界面干干净净，没有项目、没有历史数据库、没有任何可以点进去的东西，只有一排按钮。装是装完了，但系统还是个空壳。这份 Desigo CC 工程配置手册讲的恰好就是从这个空壳状态出发，把一套能跑起来的楼控系统搭出来的那段过程：建历史数据库、实例化项目、配置项目、备份数据库。它面向的是要独立完成一次部署的调试工程师和系统集成人员，不是给运维看的功能介绍。读完你应该能判断：哪一步顺序不能反、哪个参数填错了后面要推倒重来、为什么恢复模板比新建项目快那么多。

2. SMC 与 HDB：先给日志数据找个落脚点

2.1 为什么历史数据库要单独建，不塞进项目库

楼控系统里有两类数据，性格完全不同。一类是配置：点位、驱动、图形、用户、逻辑视图，改动频率低，但每一处都要精确，错一个点位的地址整条链路就断。另一类是运行数据：活动日志、报警及处理过程、批处理消息、趋势采样值和上传记录，写入频率高、只增不改、随时间线性膨胀。Desigo CC 把这后一类全部丢进历史数据库（HDB），交给 SQL Server 托管，而项目本身只管配置。

这个拆分带来的直接好处是备份策略可以分开定。项目库小，可以每天全量；HDB 大，可以按周做完整备份加日志备份。反过来，如果图省事把日志表塞进项目库，备份窗口会被日志体积拖死，一次恢复要等几个小时，恢复出来的还是一堆跟当前配置无关的历史流水。另外一个现实原因是 SQL Server 可以不在 Desigo CC 服务器上。中大型项目里，把 HDB 放到独立的数据库节点上跑，Desigo CC 服务器只负责采集和呈现，I/O 压力能分开。

这里有个容易忽略的点：HDB 不是可选项。没有 HDB，趋势曲线画不出来，报警历史查不到，事件日志一片空白。系统能启动、能看到实时值，但所有“回头看”的能力都没有。所以部署顺序上，HDB 要在项目实例化之前或者紧随其后建好，项目配置阶段才有地方挂。

2.2 扫描与链接 SQL Server 的实际路径

SMC 的入口在开始菜单里：所有程序 → Desigo CC → 工具 → Desigo CC SMC，桌面上通常也有一个。打开之后先看左边的导航，项目列表和数据库列表是分开的两块，新手最容易在这里搞混——先把 SQL Server 链接进来，才能创建 HDB；先有 HDB，项目才能关联。

SMC 提供了一个扫描功能，两种模式：扫描本地，只找本机上安装的 SQL Server 实例；扫描网络，找网段内可发现的实例。扫描结果会列成一个清单，选中目标实例点“链接”，这个实例就进了 SMC 的可用服务器池。链接这一步本身不创建任何东西，只是在 SMC 里登记一条连接信息。

扫描失败的场景比成功的还多，绝大多数不是 SMC 的问题。常见原因有三个：SQL Server Browser 服务没启动，命名实例就发现不了；TCP/IP 协议在 SQL Server 配置管理器里被禁用，只开了共享内存；防火墙挡了 1433 或者动态端口。我一般的做法是先不依赖扫描，用命令行确认连通性，确认通了再回 SMC 点扫描。这样能把“网络问题”和“SMC 问题”分开，省掉大量来回猜的时间。

# 探测目标 SQL Server 实例是否可达，并列出实例上的数据库 $server = "SQLNODE01\DESIGO" # 换成实际实例名；命名实例要带反斜杠后缀 $host = ($server -split '\\')[0] $port = 1433 # 默认实例 1433；命名实例的实际端口去配置管理器查 Test-NetConnection -ComputerName $host -Port $port # 用当前 Windows 身份连上去列库，确认 HDB 是否已经存在 sqlcmd -S $server -E -Q "SELECT name, state_desc, recovery_model_desc FROM sys.databases"

这段脚本解决的是“到底通不通”这个问题。Test-NetConnection走的是 TCP 层，只验证端口开放，不验证身份验证能不能过；sqlcmd -E用的是当前登录用户的 Windows 凭据，能过说明至少这个账户有登录权限。注意 SMC 后续创建 HDB 时用的是服务账户，不是你当前登录的账户，所以这一步通过不代表 SMC 一定能建成功，服务账户的权限要单独确认。-S后面的实例名格式是“主机名\实例名”，默认实例只写主机名。

2.3 HDB 参数怎么填：库大小、日志、恢复模式、文件位置

链接成功后点“添加”，进入 HDB 的参数页。这一页填的东西不多，但每一条都影响后面几个月会不会半夜被叫起来。

容量估算的粗算法：点位数 × 采样间隔对应的日记录条数 × 单条记录字节数 × 保留天数。趋势点如果是 15 分钟采一次，一个点一天 96 条；1000 个趋势点就是 9.6 万条一天，加上事件和活动日志，一年下来几个 GB 是常态。报警风暴型的项目（比如消防联动多的）要在这个基数上再乘 2 到 3。这个数字不用精确，量级对了就行，因为库建小了后期扩文件虽然能扩，但扩的瞬间业务是有感知的。

“HDB 所有人”这一栏值得多说一句。它不是登录账户，是数据库所有者，决定的是这个库归谁管。有些现场图快直接用域管理员，后面做权限审计的时候非常难拆。稳妥做法是建一个专用的服务账户，只授予这一个库的 db_owner，跟系统管理员账户分开。

2.4 创建完成后的第一件事是验证，不是继续往下点

点保存之后 SMC 会跑一段创建流程，几十秒到几分钟，最后给一个确认界面。这里不要看到“成功”两个字就关掉窗口往下走，回到 SQL 那边核一遍实际落盘的东西。

-- 核对 HDB 的数据文件、日志文件大小、增长方式和物理路径 SELECT DB_NAME(database_id) AS db_name, name, type_desc, size * 8 / 1024 AS size_mb, -- 页数 × 8KB 换算成 MB growth, is_percent_growth, physical_name FROM sys.master_files WHERE DB_NAME(database_id) = 'DesigoCC_HDB';

size * 8 / 1024是把 SQL Server 内部的页数换算成 MB，因为size列的单位是 8KB 页。is_percent_growth如果是 1，说明文件是按百分比增长的，这在生产库上要改掉——按百分比增长在大库上每次扩的幅度会越来越大，改成固定 MB 更好控。physical_name直接暴露文件落在哪个盘，如果发现跑到 C 盘去了，趁现在没数据赶紧重建，比半年后迁移省事得多。库名换成你实际起的名字，SMC 里建的时候起什么这里就查什么。

3. 实例化项目：模板、备份、新建三条路，为什么模板能省半天

3.1 三条路径的代价对比

SMC 给了三种把项目弄出来的方式：恢复项目模板、恢复项目备份、创建新项目。手册里明确写了推荐第一种，理由写得很克制——“花费的时间明显减少”。实际情况比这句话严重得多。

“创建新项目”看着最干净，实际上是最坑的一条。空白项目里没有扩展模块、没有图形文件夹结构、没有事件架构、没有预置的用户组和安全作用域。这些不是点几下就有的，是一整套约定。手工搭一遍，快则大半天，慢则两天，而且每搭一次结构都不完全一样，后面交接给别人就是灾难。

模板不一样。模板是预先配置好的项目基线，里面已经带了系统设置、应用程序设置、已激活的扩展模块、图形文件夹、事件架构、拓扑图形、客户端和用户配置文件、按类别分好的报告、已创建并启动的驱动、趋势定义、网络与驱动分配、逻辑视图物理视图用户视图、用户和安全组以及分配好的作用域和应用程序权限。换句话说，你拿到的不是一张白纸，是一套已经按行业惯例搭好骨架的房子，剩下的是往里填这个项目自己的东西。

3.2 恢复模板的完整操作序列

路径是固定的：模板放在安装目录下的GMSProjects\GMSMainProject\ProjTemplates，SMC 里点“恢复项目模板”会直接打开这个文件夹让你选。选模板的时候注意文件名里带的专业方向标识，BA、消防、TBS 各有各的模板，选错方向后面扩展模块是冗余的，删起来比加还麻烦。

整个序列我习惯按这个顺序走，中途不跳步：

1. 确认 HDB 已经建好并且状态正常，先有库再建项目，避免项目建完发现挂不上数据库。
2. SMC 里点“恢复项目模板”，从ProjTemplates里选目标模板。
3. 输入项目名称。命名规则提前跟现场约定好，一旦写进路径后面改要动一堆引用。
4. 确认项目路径。默认路径可以接受，但要确认所在磁盘剩余空间，项目文件夹加上日志后续会持续增长。
5. 把项目链接到第 2 章建好的 HDB。
6. 检查端口号，只有一个项目时保留默认值。
7. 保存，等恢复流程跑完。

第 3 步和第 4 步看着是小事，实际是最容易留下后患的两步。项目名称里带空格、带中文、带特殊符号，在某些客户端连接场景下会出问题，稳妥做法是纯英文加下划线。路径不要放在用户目录下，服务账户对用户目录的访问权限经常是缺的，装的时候好好的，重启服务就起不来。

3.3 端口号：单项目随便，多项目必须算

手册里这段话说得很直白：只有一个项目实例时保留默认端口；SMC 里存在多个项目时，两个已启动的项目不能有相同端口号，端口号跟活动项目冲突的项目无法启动。这句话的分量在于“无法启动”四个字——不是报个警告，是直接起不来。

多项目并存在实际项目里很常见：一个园区分期建设，一期二期各自一个项目；或者一套服务器上同时跑调试项目和正式项目。这时候端口分配要提前做张表，写清楚哪个项目用哪一段，别等到第二个项目起不来才回头翻。

# 列出当前监听中的端口，确认目标端口没有被别的进程占住 Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -ge 8000 -and $_.LocalPort -le 8100 } | # 端口段按 SMC 项目属性页显示的实际值调整 Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort

这段的用处是在启动项目之前先看一眼端口占用。LocalPort范围要换成你在 SMC 项目属性里看到的实际端口段，不要照抄。OwningProcess拿到进程 ID 之后可以用Get-Process -Id反查是哪个程序占的，如果发现是上一个没退干净的项目实例，杀掉比改端口省事。注意区分“监听”和“已建立连接”，筛-State Listen才是有意义的占用。

3.4 “已过期”不是错误，但必须处理

恢复流程跑完之后，第一件要看的是“项目和系统信息”选项卡里的状态。如果状态报“已过期”而且显示红色，说明这个项目的版本低于当前安装的软件版本，必须升级。这不是可选动作，带着过期状态启动，后面配置阶段会出现字段对不上、组件加载失败这类很难定位的问题。

升级动作本身就在 SMC 里，点一下等它跑完，中间不要中断。升级前把项目备份做掉，这是唯一一次“升级失败还能退回去”的机会。升级完成后重新看状态，变成正常再往下走。

最后一步是启动项目。SMC 里多个项目并存时，需要手动激活目标项目，不是自动切的。启动之后看标题栏显示的活动项目名称对不对，再看项目状态是不是“已启动”。标题栏和状态栏这两处是判断“我现在操作的到底是不是我以为的那个项目”的唯一依据，多人协作的现场尤其要看，改错项目的事故不少见。

4. 项目配置三件事：事件处理、共享权限、客户端连得上

4.1 事件处理行为：报警从哪来、往哪去

项目实例化出来之后能启动，但事件处理的行为还没定。手册里把这一步叫“配置项目，以控制事件处理的行为”，落到操作上是围绕事件架构展开的一组设置：什么事件算报警、报警分几级、各级对应什么处理动作、事件日志记多细、批处理消息怎么归类。

模板里已经带了一套事件架构，直接能用，但不是每个项目都能原样用。判断要不要改的标准很实际：看现场的设备类型和报警密度。一个以暖通空调为主的 BA 项目，报警密度低，模板的默认分级基本够用；一个带消防联动或者大量门禁点位的项目，事件量级完全不同，默认架构下事件日志会被刷得很快，重要的故障信息淹没在噪声里。

具体的调整方向有三个。一是报警类别，把“设备故障”“通信中断”“越限报警”分开，不要全塞进一个通用类别，否则后期查历史只能靠关键字搜。二是优先级，影响到安全或者大面积停机的往上提，传感器瞬时抖动这类往下压或者加延时确认。三是批处理消息的归类，这类消息记录的是“已发生的故障”，跟实时报警是两条线，混在一起会让统计报表失真。

改完事件架构一定要重启项目再验证，部分事件配置在项目运行态下不生效。验证方法也简单：人为制造一个能被捕获的事件（比如断开某个驱动通道），看事件日志里有没有按新配置的类别和优先级记下来。这一步花十分钟，能省掉后面调报表时的一堆怀疑。

4.2 项目文件夹共享与客户端连接权限

这一节是整份手册里最容易被跳过、又最容易在现场翻车的地方。Desigo CC 是客户端/服务器结构，客户端要连上来，必须能访问服务器上的项目文件夹。默认安装完成后，共享和权限不一定配好了。

需要确认的层次有三层，缺一层客户端就连不上或者连上了读不到数据：

共享层和 NTFS 层是 Windows 的事，应用层是 Desigo CC 自己的用户和安全组体系。三层要同时对，只有一层对是没用的。我见过只配了共享没配 NTFS 的情况，表现是客户端能连上、能看实时值，但一操作就报错，日志里全是访问被拒，排查方向很容易被带到应用层去。

NTFS 权限给到什么程度要看角色。只读监视的客户端给读加执行就够；要操作点位、确认报警的，必须给修改；工程调试用的账户权限最高，但这个账户不应该发给日常运维。共享权限和 NTFS 权限取交集，两边都要放开，只放一边等于没放。

4.3 客户端连上之后要验的三件事

客户端能登录不算成功，登录之后要逐项验。第一件，实时值刷新是否正常，找一个变化快的模拟量点位盯着看几十秒，值不刷新说明数据通道有问题，不是权限问题。第二件，历史趋势能不能拉出来，这一条直接验证 HDB 链路是否打通——趋势拉不出来但实时值正常，问题一定在 HDB 那边，跟客户端无关。第三件，报警能不能确认，这一条验证的是写权限和事件处理的联动。

这三件事按顺序验，出问题时能快速定位到是哪一层。顺序颠倒的话，比如先验报警确认，失败了你不知道是权限问题还是事件架构问题还是 HDB 问题，只能一层层往回猜。

多人同时在线的时候还要看并发表现。几个客户端同时拉长跨度趋势，服务器响应会明显变慢，这是 HDB 查询压力，不是故障。如果慢到影响操作，考虑把趋势查询的时间跨度在客户端配置里限制一下，或者把 HDB 挪到独立数据库节点。

5. 五条踩坑记录：从权限到端口的排查顺序

5.1 扫描不到 SQL Server，但用工具能连上

现象：SMC 里点“扫描本地”或“扫描网络”，列表是空的，可是用管理工具连同一个实例完全正常。

原因：SMC 的扫描依赖 SQL Server Browser 服务做实例发现，这个服务默认是手动启动甚至禁用的。命名实例不走 1433，端口是动态分配的，没有 Browser 服务就没法把实例名解析成端口。另外 SQL Server 网络配置里如果只启用了共享内存协议，跨机器扫描同样发现不了。

解决：把 SQL Server Browser 服务改成自动启动并拉起来，在配置管理器里确认 TCP/IP 协议已启用，然后重启 SQL Server 服务。如果现场不允许开 Browser 服务，就跳过扫描，直接在 SMC 里手工填实例名和端口，效果一样。

5.2 HDB 创建成功，但趋势数据一直是空的

现象：SMC 里 HDB 状态正常，项目也关联上了，客户端能看实时值，趋势曲线怎么拉都是空白。

原因：项目关联 HDB 和趋势定义写入 HDB 是两件事。项目配置里的趋势定义如果没启动，或者趋势点的采样周期配成了 0 或者一个极大的值，数据根本不会往里写。另一种情况是 HDB 关联的时候选错了库，指向了另一个同名的测试库。

解决：先查 HDB 里数值日志表有没有记录，一条都没有就是没在写；有记录但客户端拉不出来，问题在客户端查询侧。确认趋势定义的状态是已启动，采样周期按实际需求设，别图省事设成分钟级还指望看秒级波动。

5.3 第二个项目起不来，报端口冲突

现象：第一个项目运行正常，恢复第二个项目之后点启动，起不来，没有任何有用的错误提示。

原因：手册里写了，SMC 中存在多个项目时，两个已启动项目不能有相同端口号，端口号跟活动项目冲突的项目无法启动。恢复模板或恢复备份时，端口号是跟着模板或备份一起过来的，不会自动避开已占用的端口。

解决：启动前先在项目属性里把端口改成没被占用的值，用 3.3 节那段命令先查一遍占用情况。项目多的时候提前做端口分配表，别每次现查。

5.4 恢复完模板，状态是红色“已过期”

现象：恢复流程提示完成，但“项目和系统信息”里状态显示已过期，颜色是红的。

原因：模板是在某个软件版本下制作的，当前安装的软件版本更高，项目结构需要升级才能匹配。这是版本差异，不是恢复失败。

解决：先在 SMC 里做一次项目备份，然后执行升级，等它跑完再看状态。升级过程中不要中断，不要同时开别的项目操作。升级完成后重新启动项目，验证扩展模块和驱动是否都正常加载——升级偶尔会有组件需要重新激活。

5.5 客户端能登录，但一操作就报访问被拒

现象：客户端登录成功，画面能打开，实时值能看，但确认报警、修改设定值全部失败，日志里是权限相关错误。

原因：项目文件夹的 NTFS 权限只给了读，没给修改。共享权限放开但 NTFS 没跟上，是这类问题的标准成因。另一种可能是应用层的作用域没覆盖到操作对象所在的视图，账户存在但权限范围不够。

解决：先看文件夹 NTFS 权限，确认客户端运行账户有修改权限；再看应用层的用户和安全组，确认作用域和应用程序权限都分配到位。两层都查完还不行，用客户端账户在服务器上直接访问一次项目路径，手动建个文本文件试试，能不能建立刻就知道是哪一层的问题。

6. 备份与恢复演练：把后悔药提前吃一遍

备份这件事，手册里给的是一套操作，但真正决定它有没有用的不是操作，是有没有演练过。我见过太多现场，备份任务天天跑，日志一片绿色，真出事要恢复的时候发现备份文件是几周前的、或者恢复出来的项目挂不上当前 HDB。备份文件的体积和修改时间只能证明“有东西生成”，证明不了“这东西能用”。

我做备份的固定顺序是：先备份 HDB，再备份项目文件夹，两个都完成才算一次完整备份。理由是这样恢复的时候方向一致——HDB 是项目运行期间的数据，项目是配置，先恢复数据再恢复配置，项目一挂上就有历史可查；反过来先恢复项目，中间那段时间项目是空跑的，容易产生新的日志污染刚恢复的库。

验证环节我一般用两条线，一条轻一条重：

恢复演练的关键是恢复到临时项目名，不要覆盖生产项目。演练完把临时项目删掉，顺便验证一次删除流程。演练里最容易暴露的问题是 HDB 关联——恢复出来的项目指向的还是旧库名或者旧实例，启动起来看着正常，一查历史就是空的。这一步必须真的去拉一条趋势、查一条报警历史，光看状态正常不算。

还有个细节：备份文件不要跟项目放在同一个卷上。同一块盘坏了，备份和原件一起没，这个道理谁都懂，但现场图方便放一起的情况一点不少。如果条件允许，备份完成后同步一份到另一台机器或者网络位置，SMC 里配好路径之后是自动的，不需要每次手工拷。

从那以后，我每次做完备份都会强制走一遍“拉一条趋势、查一条报警历史”的验证，哪怕只是三十秒的事，也不允许自己跳过。备份没验证过就等于没有备份，这句话在楼控现场不是危言耸听。希望帮到你。

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