企业官网建设流程全解析

简介：西门子 Desigo CC 手册「Project Configuration（工程配置）」章节，面向楼宇自动化系统的项目工程师与运维人员，解决从零建立并维护工程项目的核心配置问题。内容围绕系统管理控制台（SMC）展开，涵盖 SQL Server 扫描、历史数据库（HDB）的创建与参数设置，以及通过恢复模板、恢复备份或新建三种方式实例化项目，并补充了项目命名、端口号冲突、升级与启动等实操注意事项。章节还讲解了配置项目事件处理、共享与安全访问权限、备份项目与数据库的方法，并配有 SMC 工作流程及操作演示，便于对照上手。资源为 1 个 PDF 文件，压缩包约 2.23MB，适合安装配置 Desigo CC 时作为离线参考文档。目前已有 554 人学习下载，适合需要理解工程配置全流程并减少现场失误的工程技术人员。

1. 工程配置是 Desigo CC 项目的“地基卷”：选错设置，调试现场两天白干

一个 2000 点位的办公楼项目，集成商在 Desigo CC 工程配置阶段把数据库排序规则选错，结果调试现场整整两天连不上 Management Station，最后只能重装数据库实例，所有点位重新导入。这种事在楼宇自控项目里并不少见：大家拿到 Desigo CC 手册第 04 卷《Project Configuration-BA-CN（工程配置）》时，第一反应往往是“等软件装完，随手点几下就行”，直到客户端连不上、操作员权限改不动、冗余切换失效，才回头翻这一卷。工程配置决定的不只是“能不能建库”，而是整个项目从单机调试到正式运行的地基：数据库实例与排序规则、站点命名、功能配置档、多服务器与冗余、数据传输队列，每一个选择都会在几个月后的现场以奇怪的方式找你算账。这一卷真正适合的读者，是准备自己创建工程数据库、做系统初始化的楼宇自控工程师和调试负责人。

2. 配置前的三道门槛：数据库实例、安装顺序与授权核对

很多团队把“装好 Desigo CC”和“配置好工程”当成同一件事，结果在创建工程数据库时反复报错。我经手过的项目里，至少有一半问题出在动手点“新建工程”之前的环境准备上。这里把三道最常见的门槛拆开说：SQL Server 实例与排序规则、组件安装顺序、授权核对。这三样不在工程配置向导里，却直接决定向导能不能跑通。

2.1 SQL Server 实例与排序规则：最先翻车的其实是数据库层面

Desigo CC 的工程数据、历史数据、报警数据都存在 SQL Server 里，安装时通常会有两种路径：一种是让安装向导自动装好自带的 SQL Server 实例，另一种是使用现场已有的 SQL Server 实例。后者最容易翻车，因为已有实例的排序规则（Collation）很可能和 Desigo CC 预期的不一致。

常见做法是先用一条 SQL 把实例的排序规则查出来：

SELECT SERVERPROPERTY('Collation') AS InstanceCollation;

如果 SQL Server 是在中文版操作系统上安装的，默认排序规则往往是Chinese_PRC_CI_AS，而 Desigo CC 安装包自带的实例通常按拉丁语系列排序规则初始化，比如SQL_Latin1_General_CP1_CI_AS。两个实例排序规则不一致，后面创建工程数据库时，向导可能报“对象名无效”或“字符串比较失败”，更有意思的是，有时候创建能成功，但 Management Station 登录后树形结构里的点位排序和查找是乱的。

我一般会在创建工程前把每个实例的排序规则再确认一次：

SELECT name, collation_name, state_desc FROM sys.databases WHERE database_id > 4;

参数说明：collation_name决定这个数据库里字符串比较和排序的方式，CI_AS表示不区分大小写、区分重音，这是多数楼控项目能正常工作的底线。如果某个业务库的排序规则和实例不一致，建议在建库前直接重建实例，而不是试图在建库后修改排序规则，因为修改排序规则在数据量大时耗时很长，而且容易把索引搞坏。

2.2 安装顺序：服务器、客户端、工程站谁先谁后

Desigo CC 的组件安装顺序不是“随便装，缺啥补啥”的逻辑。正确的顺序是：先装 SQL Server（或由安装向导统一装），再装服务器端组件，最后装客户端和工程站组件。如果现场先把 Management Station 客户端装好，再去补服务器端，注册信息和系统服务之间的关联经常会断，表现是客户端启动时找不到服务器。

安装顺序背后其实是服务依赖关系。服务器端组件负责数据库访问、报警处理、历史数据归档，客户端通过 OPC UA 连接服务器；反过来装，客户端的连接配置会写入一个不存在的服务器条目，后面排查起来很别扭。

装完后，我习惯用两条命令从网络层确认关键服务已经监听：

netstat -ano | findstr ":1433" netstat -ano | findstr ":4840"

参数说明：1433是 SQL Server 默认端口，4840是 OPC UA 默认端口。两条命令都有LISTENING输出，说明数据库和通信服务起来了；如果只有一条，先不要急着创建工程，先把对应的 Windows 服务启动，再继续。注意：如果 SQL Server 配置成了命名实例，它的端口可能是动态的，这种情况下需要先打开 SQL Server 配置管理器，把端口固定下来，否则防火墙规则没法写。

2.3 授权与系统限制：先把点数、服务器数摸清楚再建工程

工程配置阶段最容易忽略的是授权核对。Desigo CC 的授权由 License Manager 管理，授权文件里写明了允许的数据点数量、客户端数量和服务器数量。很多人先把工程数据库建好，再导入授权文件，结果建库时系统把“无授权”状态写进了工程配置，后面虽然导入了授权，部分功能仍然不生效，表现为某些视图能看不能操作，重启服务后可能又恢复。

正确的顺序是“先授权，后建库”。拿到授权文件后，先在 License Manager 里导入并确认状态为“已激活”，再开始创建工程数据库。建库前还要做一次点数和服务器数的摸底：这个项目是单站单服务器，还是多服务器冗余，总共要接入多少数据点，有没有第三方系统连接。

这里给一个核对用的表格模板，我在项目启动阶段会照着填一遍：

这一步多花十分钟，能省下工程配置后“功能灰掉”“报警不推”这类返工。授权核对不用记太多参数，核心是记住一件事：工程数据库是在授权快照之上建立的，授权没落地之前，不要点“新建工程”。

3. 从空库到能跑：创建工程数据库的完整步骤与三个隐藏参数

环境准备做完，才轮到真正的 Project Configuration。这一章把从空库到 Management Station 能登录的最小路径走一遍。除了向导里肉眼可见的数据库名称和站点名称，还有三个隐藏参数，后面现场出问题多半和它们有关。

3.1 创建工程数据库：站点命名与站点 ID 的硬规则

在服务器上打开 System Configuration（系统配置），进入工程管理页签，选择新建工程数据库。向导会让填三样东西：数据库名称、站点名称和站点 ID。注意，这不是随便填的字段，它们会出现在后续所有客户端的连接字符串、控制器通讯地址和报表标签里。

我一般用这样的规则：

• 数据库名称：项目缩写加上_BA，例如HQ_BA，纯英文，不用下划线开头。
• 站点名称：大写字母加数字，不超过 10 个字符，例如HQ_MAIN。
• 站点 ID：一个整数，用于区分同一套 Desigo CC 管理下的不同楼宇站点。如果后续要接多个站点，站点 ID 不能重复。

为什么这么强调“纯英文、短”？因为 Desigo CC 的服务器名称、数据库名称、站点名称会被写入到 OPC UA 地址和日志文件路径中，中文或带空格的名称在部分组件的编码处理下会出问题，日志文件路径解析失败后，服务可能起不来。这不是“玄学”，而是字符编码在跨组件传输时的一致性问题。

向导结束时，系统会创建数据库并初始化基础数据结构。完成后不要急着关窗口，先验证一下数据库状态：

SELECT name, state_desc FROM sys.databases WHERE name = 'HQ_BA';

参数说明：state_desc返回ONLINE才正常。如果返回RECOVERY_PENDING或OFFLINE，先不要重试创建，把 SQL Server 错误日志打开看原因，多半是权限或磁盘路径问题。

3.2 功能配置档：操作员、值班长、工程师不要共用一套

工程数据库建好之后，下一步不是急着建点位，而是把用户和功能配置档建好。Desigo CC 的功能配置档（Function Profile）决定一个登录用户能看哪些视图、能不能下发命令、能不能改设定值。默认模板通常是“操作员”“工程师”这类通用档，但实际项目里，现场值班人员和调试工程师的需要完全不同。

我一般会复制默认模板，改成三个自定义档：

• Operator（值班操作员）：只能看报警、趋势和当前值，不能下发命令。
• Operator Supervisor（值班长）：在 Operator 基础上，可以手动启停设备、修改设定值。
• Engineer（调试工程师）：全部权限，包括图形编辑、点位配置和工程传输。

在用户管理里，把现场值班人员的账号绑到 Operator 和 Operator Supervisor，而不是图省事全部给 Engineer。这一步看起来和“工程配置”关系不大，但后期最影响运行安全。调试阶段用 Engineer 没问题，项目移交后一定要把账号权限收敛回去。

设置功能配置档时注意一个参数：修改配置档后，已经登录的用户不会立即生效。现场反映“权限改了没用”时，第一反应应该是让用户退出重新登录，而不是再去改配置档。如果配置档本身处于被引用状态，有的版本会限制编辑，表现为“保存成功但重新打开还是老样子”，这种情况把引用它的用户先移动到另一个档，改完再移回来。

3.3 从 Excel 批量导入设备与点位：模板格式与四个边界坑

工程配置里最耗时的部分是点位导入。常见做法是先用系统自带的导出功能生成一份 Excel 模板，然后在模板里填点位信息，填完再导入。不要自己凭感觉新建 Excel 表，因为表头的列名和对象路径格式必须严格按模板来。

模板的核心字段通常是这样几列：对象路径、对象类型、点位地址、数据类型、初始值、所属设备。对象路径是 Desigo CC 里最关键的字段，它决定了这个点位挂在哪个站点、哪个子系统、哪台控制器下面。路径写错一位，点位就会跑到错误的位置，而导入工具不会报错，因为它只校验格式，不校验语义。

导入时的四个边界坑：

1. 对象路径的分隔符和大小写必须与模板导出一致，手动敲路径容易把反斜杠或多级路径敲错。
2. 点位地址必须与控制器的实际地址表对应，导入工具不关心地址是否真实存在，现场连不上才会发现。
3. 一次不要导入上万行，我习惯按子系统分批，每批 500 行以内；报错时能直接定位到行，不用在几千行里翻。
4. 导入前一定先做一次数据库备份，导入后发现问题可以快速回到导入前状态，这是工程配置阶段唯一的“后悔药”。

导入完成后，点位在管理站里可能显示为红色或离线状态。这不代表导入失败，而是控制器通讯还没建立。第一步先确认控制器本身在线，再看点位地址和通讯参数，不要急着反复导入。

4. 从单机到生产环境：多服务器与冗余的配置边界

工程配置做到这里，单机系统已经能跑了。但绝大多数正式项目不是单机：要么有备用服务器做冗余，要么有多个客户端同时访问。这一章讲多服务器与冗余的配置边界，重点是搞清楚什么场景需要冗余，以及冗余配置里的参数到底在调什么。

4.1 什么时候需要多服务器：别让“高可用”成了摆设

不少项目一上来就要求“双服务器冗余”，但实际点数只有几百点，历史数据量也不大。冗余配置不是免费的：它意味着两台服务器、数据库同步、心跳网络、切换演练，还有一台服务器在故障瞬间可能产生的数据缺口。对没有连续性运行要求的项目，单服务器加定时备份其实是更务实的选择。

什么场景确实需要冗余？我的判断标准有三个：

• 冷站、手术室、数据中心这类不能停控的场景。
• 历史数据和报警记录需要持续归档，不能接受长时间数据缺口的场景。
• 客户端数量和点位规模已经超过单台服务器的稳定承载范围。

真正做多服务器时，一个常见的误区是把一个站点的管理职责拆到多台服务器上。Desigo CC 的工程配置逻辑是“一个站点对应一个服务器组”，而不是“一个站点拆给多个服务器”。如果点数确实多到单台扛不住，应该先做站点拆分，而不是在同一站点下加服务器。

多服务器组的配置关键项主要有三个：服务器优先级、历史数据存储路径、数据传输同步周期。优先级决定了主备切换时谁先接管；存储路径要规划在数据盘而不是系统盘；同步周期不要太长，否则故障时会丢数据。

4.2 冗余配置参数与切换验证

冗余配置在系统配置里完成，核心是建立一个服务器组，把主服务器和备用服务器加进去，然后设置同步关系。主备服务器之间需要通过网络实时同步数据库和历史数据，这个过程依赖的是数据传输（Data Transfer）机制。

配置时几个参数要注意：

• 心跳超时时间：主服务器和备用服务器之间互相检测心跳，超时后备用服务器会接管。这个值不要设得太短，网络闪断可能引起误切换；也不要设得太长，否则故障后接管太慢。现场常见的设置在 30 到 60 秒之间。
• 数据同步周期：主服务器把数据推给备用服务器的间隔。周期越短，故障时丢失的数据越少，但对网络带宽要求越高。
• 账号与时间同步：两台服务器必须在同一时钟源下，时间不一致会导致报警排序和趋势记录错乱。

配置完成后，一定要做一次真实的切换演练，步骤是：登录管理站，确认主备状态正常，然后直接拔掉主服务器的网线，观察管理站是否在配置的超时时间内自动连接到备用服务器，并继续显示数据和报警。恢复主服务器网线后，观察主服务器能否重新接管。

这里有个血泪经验：演练前一定先做一次数据库备份，并确认数据传输队列已经清空。否则切换瞬间队列里堆积的数据会在恢复后重传，可能导致备用服务器上的数据重复或曲线断档。

4.3 客户端访问配置：Hosts、端口与证书

客户端连不上服务器，是工程配置阶段出现频率最高的问题之一。排查时先分清楚是网络层、名称解析层还是加密层。

名称解析层最常见的坑是 DNS 解析不到服务器名。现场很多服务器没有配 DNS 后缀，客户端用服务器名解析失败，直接填 IP 又能通。但我不建议在客户端连接里直接写 IP，因为冗余切换时服务器的 IP 是会变的。正确做法是在客户端的 hosts 文件里手动加一条映射：

192.168.10.10 HQ_BA-SRV1 192.168.10.11 HQ_BA-SRV2

参数说明：192.168.10.10和192.168.10.11换成实际 IP，HQ_BA-SRV1和HQ_BA-SRV2是两台服务器的名称。这样无论冗余切换还是服务器重启，客户端始终通过名称访问，IP 变化时只需要改 hosts，不用改客户端配置。

端口层面，除了前面提到的 SQL Server 1433 和 OPC UA 4840，还要注意 SQL Server Browser 服务的 UDP 1434。如果 SQL Server 配置成命名实例，客户端查动态端口时要靠这个服务。防火墙规则可以把这三条一起放行，但不要图省事直接关防火墙。

加密层的问题通常表现为客户端提示“证书不受信任”。正式环境应该把服务器证书导入到客户端受信任根证书存储区；如果只是内网调试，可以在连接设置里临时关闭加密，但项目移交前一定要恢复加密并重新信任证书。忽略证书问题强行绕过，后续客户端升级时大概率会再次踩坑。

5. 避坑排查：工程配置阶段我遇到的 6 个高频事故

这一章专门写给正在现场和配置向导“搏斗”的人。以下六条来自实际项目里的踩坑记录，每一条都按“现象、原因、解决”展开，可以直接对照排查。

5.1 创建工程数据库时提示“SQL Server 登录失败”

现象：在 System Configuration 里新建工程数据库，向导走到一半报错“SQL Server 登录失败”或“连接超时”，重试多次结果一样。

原因：Desigo CC 的服务账号没有目标 SQL Server 实例的登录权限，或者 SQL Server 是命名实例但 SQL Browser 服务没启动，客户端解析不到动态端口。

解决：先在 SQL Server 里检查账号：

SELECT name, type_desc FROM sys.server_principals;

确认 Desigo CC 安装时指定的服务账号存在，并至少拥有sysadmin角色。接着确认 SQL Browser 服务已启动，防火墙放行 UDP 1434。如果用的是命名实例，另一种更稳的做法是把 SQL Server 的端口固定为 1433，省去动态端口解析的环节。

5.2 客户端能连服务器，但点位和视图加载不出来

现象：管理站能登录，但树形结构迟迟加载不出来，或加载出来以后全是空节点。

原因：这个现象经常和“建库时选择了不正确的排序规则”有关。字符串比较失败后，对象名称在查询结果里对不上，界面就显示为空。另一种原因是客户端和服务器版本不一致，客户端版本比服务器旧时，可能出现部分视图不兼容。

解决：先用数据库查询确认对象是否真的存在，再判断是排序规则还是版本问题。排序规则问题只能重建实例并重新导入数据。版本问题则把客户端升级到与服务器一致的版本。客户端版本落后是常态，建议每次做工程配置前先确认版本号一致。

5.3 功能配置档改不动，保存后又恢复原样

现象：在用户管理里修改了功能配置档的权限，点击保存提示成功，但重新打开配置档，界面还是老样子。

原因：这个配置档正在被一个已登录用户引用。Desigo CC 的配置机制不允许直接修改正在使用的配置档，有的版本不会给出明确提示，只是静默拒绝。

解决：先到用户管理里找到引用这个配置档的所有用户，把他们临时移动到别的配置档，修改完成后再移回来。如果现场有操作员正在值班，移回来时注意不要覆盖他当前的工作界面。这个问题在项目移交阶段尤其容易出现，因为值班账号长期占用“操作员”档，导致配置无法修改。

5.4 服务器重启后管理站长时间连不上

现象：服务器因为补丁或断电重启，启动完成后 Management Station 一直提示“正在连接”，持续几分钟甚至更久。

原因：Desigo CC 的服务器服务启动顺序依赖数据库服务和授权服务。SQL Server 没有完全就绪时，Desigo 服务可能反复重试，授权服务没有启动时，服务器会拒绝客户端连接。

解决：在服务器上用服务管理器按顺序检查，确认 SQL Server 服务先运行，再启动授权服务，最后启动 Desigo 服务器服务。不要手动反复重启服务，等它完成初始化。可以用命令行辅助查看：

sc query MSSQLSERVER

参数说明：MSSQLSERVER是默认实例的服务名，如果是命名实例，服务名可能是MSSQL$实例名。服务状态为RUNNING后再启动 Desigo 服务，连接速度会快很多。

5.5 冗余切换后历史数据缺了一段

现象：主服务器故障，备用服务器正常接管，但查看历史趋势时发现故障前后的一段数据缺失，有时长达几十分钟。

原因：主服务器在故障瞬间，数据传输队列里的数据还没来得及同步到备用服务器。冗余保护的是“在线可用性”，不保证“零丢失”，同步周期越长，丢的数据越多。

解决：缩短数据传输同步周期，并定期检查队列长度。检查队列长度的方法是在服务器上打开系统监控，查看数据传输服务的队列计数。如果队列经常不为零，说明主备之间的同步带宽或周期设置不合理，需要调优。另外，切换演练前先手动触发一次同步，确认队列清空后再演练，避免演练本身造成数据缺口。

5.6 恢复备份后客户端功能异常

现象：服务器故障后，用备份文件恢复了数据库和服务，客户端能登录，但部分功能不可用，比如报警不推送、历史趋势查询报错。

原因：备份文件和当前服务器程序版本不一致。常见场景是备份是旧版本时期做的，服务器已经升级过，恢复数据库后，旧库结构和新程序不匹配。

解决：用 Desigo CC 自带的备份恢复工具做整库恢复，不要用 SQL Server 的备份功能单独恢复数据库，因为 Desigo CC 的备份里还包含授权状态、服务配置和文件系统里的工程文件。恢复完成后，先重启服务器服务，再打开管理站验证。版本升级前做的备份最好标注日期和版本号，方便回退时找到正确的备份。

6. 配置验证与进阶习惯：用系统监控、数据队列与版本校验兜住最后一道

工程配置不是“建完库就结束”，而是要在投入调试之前确认系统真的处于健康状态。我的验证习惯分三层：服务状态、数据传输队列、版本一致性。

第一层在管理站打开系统监控视图，确认服务器服务、数据传输服务、授权服务全部在线。服务状态绿色不等于数据库连接正常，所以第二层要看数据传输队列长度，队列持续不为零，说明有离线数据没有上送完，需要等它消化，或者查网络带宽。第三层验证数据库状态，执行：

SELECT name, state_desc FROM sys.databases WHERE name = '你的数据库名';

结果必须是ONLINE。如果状态是RECOVERY_PENDING，基本可以判断数据库文件损坏，这时候不要反复重启服务，应该先停服务，用备份恢复。

版本一致性是我最近几年特别在意的检查项。服务器程序版本、客户端版本、数据库备份版本三者必须匹配。我给自己定了一条规矩：每次做工程配置或版本升级前，先记录服务器和客户端的版本号，再动数据库。升级时先把备份文件命名为“站点名_日期_旧版本号”，放在数据盘单独的备份目录里，而不是丢在系统盘默认目录下。这样万一新版本有问题，回退时能找到干净的旧备份。

另外一个长期有用的习惯是把每个项目的“工程配置参数表”更新到项目文档里，包括 SQL Server 实例名和排序规则、站点名称和 ID、服务器组节点、授权文件号、功能配置档列表。很多看似“玄学”的问题，最后回到这张表都能找到原因。从第一次用 Desigo CC 到现在，我始终会在工程配置阶段多花半天检查数据库排序规则、授权状态和数据传输队列；现场调试顺利的项目，几乎都是这个阶段没有埋雷。希望帮到你。

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