简介《Desigo CC手册-04-Project Configuration-BA-CN工程配置》是西门子面向楼宇自动化工程实施与运维人员整理的项目配置指导文档适合已接触Desigo CC、需要完成系统落地配置的初中级读者查阅。压缩包内为1个PDF文件约2.23MB内容围绕系统管理控制台展开依次讲解历史数据库创建、项目模板恢复与实例化、项目事件处理和共享权限配置、项目及历史数据库备份等核心任务并补充SMC工作流程与操作要点。已有562人学习说明其在同类工程配置资料中具备一定参考价值。读者可据此梳理从建库、建项到备份的完整配置链路理解模板化部署对缩短工程时间和降低出错风险的作用也可将手册中的流程说明作为现场实施、客户端连接设置与日常维护的对照依据。1. 手册翻到「工程配置」这一章先把 SMC 的账算明白接手一套楼宇自控系统最怕的不是画点画图而是拿到一台刚装完 Desigo CC 的服务器打开系统管理控制台SMC面对一片空白不知道第一个按钮该点哪儿。这份手册的工程配置章节解决的正是这一段的活先在 SMC 里把历史数据库建起来再从模板或备份实例化出项目绑库、配端口、开共享权限最后把项目和库一起备份走。它服务的不是运营期而是现场调试到交付前那几天——尤其是要在一台服务器上并存多个项目、或者接手别人留下的备份包的人。SMC 在这个流程里承担四件事配系统和默认用户账户、创建/恢复/升级项目、给项目挂扩展模块、创建或恢复项目专用的 SQL 历史数据库。把这四件事的先后顺序搞反后面每一步都会加倍返工。下面按我实际动手的顺序拆一遍哪些参数必须改、哪些默认值别动、哪一步翻车最难查都写清楚。2. 历史数据库 HDB从扫描 SQL Server 到建库参数的完整落地2.1 为什么 HDB 要单独规划而不是跟着项目走HDB 记录的是四类东西用户活动活动日志、警报及其处理过程事件日志、已发生的故障批处理消息、趋势数据值和上传数值日志。这四类的共同点是随时间线性膨胀而项目库本身是配置数据装完基本不变。把两者放在同一个库里会带来三个直接后果备份窗口被日志撑大、恢复粒度被绑死想只回滚配置就得连几个月的趋势一起回滚、磁盘 IO 互相打架趋势写入是持续的小事务配置读取是偶发的大查询。所以我在做工程配置时第一件事永远是给 HDB 单独规划磁盘。判断标准很简单HDB 的数据文件和日志文件放在不同物理盘上且日志盘的剩余空间要能覆盖「两次完整备份之间的日志增长量」。如果现场只有一块盘那就至少要给日志文件设一个硬性上限并配日志备份别让它无限长——这一点后面避坑章节会展开。2.2 扫描、链接、添加三步走完 SQL Server 挂接SMC 不自己造数据库引擎它扫描网络上已有的 SQL Server 实例把选中的实例链接进来再在实例上「添加」出一个 HDB。扫描分两种扫描本地只搜当前机器扫描网络会去搜整个网段。现场经验是网络扫描在跨网段、有防火墙的环境下经常扫不全我一般先用本地扫描确认引擎本身是通的再决定要不要走网络扫描。在打开 SMC 之前先花两分钟确认 SQL Server 是活着的、实例名和端口是通的# 查本机所有 SQL Server 服务实例确认引擎已启动 Get-Service | Where-Object { $_.Name -like MSSQL* } | Select-Object Name, Status, StartType # 查 SQL Browser 服务命名实例的扫描依赖它 Get-Service | Where-Object { $_.Name -like SQLBrowser* } | Select-Object Name, Status # 确认 1433默认实例是否在监听命名实例走动态端口则看 UDP 1434 Get-NetTCPConnection -LocalPort 1433 -ErrorAction SilentlyContinue | Select-Object LocalAddress, LocalPort, State, OwningProcess逻辑说明第一条确认数据库引擎服务在跑服务停着的时候 SMC 扫描会一无所获但界面不会告诉你原因只会显示列表为空这是最常见的误判点。第二条针对命名实例——SMC 的网络扫描靠 SQL Browser 服务广播实例信息这个服务被禁用时命名实例就「隐身」了而默认实例仍然可见于是很容易得出「网络没问题、就是扫不到」的错误结论。第三条确认端口监听状态防火墙放行了服务但没放行端口的情况在现场很常见。参数说明如果现场用的是命名实例SMC 里填的主机名要写成主机名\实例名的形式只写主机名会连到默认实例上去。SQL Server 如果配了非默认端口扫描能发现但链接会失败这时需要在实例配置里显式指定端口别指望自动发现。扫描到实例后点「链接」再点「添加」SMC 会弹出一个 HDB 配置页。这一步注意链接只是把实例登记进 SMC添加才是真正建库两个动作别混。有些现场环境权限收紧链接能成功但添加会失败报错通常是权限不足或磁盘路径不可写看的是 SQL Server 服务账户对目标目录的权限不是当前登录用户的权限。2.3 HDB 参数表六个字段决定这个库以后好不好养建库页面上的字段不多但每一个都影响后续运维我按重要程度排一遍参数常用取值选择理由与边界数据库初始大小按点位数估留 2 倍余量太小会频繁自动增长增长瞬间有卡顿太大占盘且首次备份慢日志初始大小数据文件的 25%50%日志过小会导致高频日志增长是趋势写入卡顿的隐性原因恢复方法完整恢复 定期日志备份要求可回滚到任意时间点若现场不做日志备份选简单恢复否则日志无限涨数据文件位置独立数据盘与操作系统盘分离避免系统盘写满导致整个库不可用日志文件位置另一块盘与数据文件分离顺序写和随机读不抢磁头/队列HDB 所有人 / 用户专用服务账户不要用个人域账号人员变动后库就没人管得动了这张表里最容易翻车的是「恢复方法」和「日志文件位置」两项。恢复方法选完整却没人做日志备份日志文件会一路涨到把盘写满SQL Server 拒绝写入趋势数据开始丢而 Desigo CC 侧只表现为趋势曲线断点排查方向很容易跑偏到驱动和网络上去。反过来日志文件和数据文件放在同一块盘上日常看不出问题一旦做完整备份备份期间的 IO 会把趋势写入拖慢报警时间戳出现毫秒级漂移对事件追溯要求高的项目是要被追责的。文件位置这一栏填的是目录不是完整文件路径。常见做法是建一个专用目录例如D:\HDB\Data和E:\HDB\Log目录提前建好并给 SQL Server 服务账户完全控制权限别让 SMC 去创建目录——它创建的目录继承的是父目录权限后面换服务账户会踩权限坑。2.4 建库完成后的自检三条查询确认库是真的能用SMC 弹出「已成功完成」不代表库处于可用状态它只代表建库语句执行完了。我习惯用三条查询做交付前自检-- 1. 确认 HDB 存在、状态正常、恢复模型符合设计 SELECT name, state_desc, recovery_model_desc, log_reuse_wait_desc FROM sys.databases WHERE name LIKE %HDB%; -- 2. 确认数据文件与日志文件确实落在不同盘符 SELECT DB_NAME(database_id) AS db_name, name, physical_name, size * 8 / 1024 AS size_mb FROM sys.master_files WHERE DB_NAME(database_id) LIKE %HDB%; -- 3. 确认自动增长设置合理没有被设成按百分比无限增长 SELECT DB_NAME(database_id) AS db_name, name, is_percent_growth, growth FROM sys.master_files WHERE DB_NAME(database_id) LIKE %HDB%;逻辑说明第一条里log_reuse_wait_desc是最有价值的一列它告诉你日志为什么不能被截断。返回LOG_BACKUP说明恢复模型是完整且等待日志备份属于设计内返回ACTIVE_TRANSACTION说明有长事务卡着通常是某个写入会话挂了没释放这种状态下日志会一直涨。第二条验证文件落盘位置防止建库时手滑把两个文件填成同一路径。第三条查自动增长方式is_percent_growth 1在大库上是灾难10% 的增长在 100GB 的库上就是一次 10GB 的分配会锁住写入好几秒。参数说明size * 8 / 1024是把页数换算成 MBSQL Server 的size列单位是 8KB 页。文件名匹配用LIKE %HDB%是因为 SMC 建库时会在库名里带上项目标识现场命名习惯不统一用模糊匹配更稳。三条都过了才回到 SMC 把项目绑到这个库上。顺序反了的话项目会绑到一个半成品库后面启动时出现的事件日志写入失败极难定位。3. 项目实例化模板、备份、新建三条路的选型与实操3.1 三条路的成本对比为什么模板是默认答案SMC 给三种实例化方式恢复项目模板、恢复项目备份、创建新项目。手册里明确推荐模板理由不是习惯问题是工程量问题。新建项目等于从零配系统设置、应用设置、扩展模块、图形文件夹、事件架构、拓扑图形、客户端和用户配置文件、报告分类、驱动、趋势定义、网络与驱动分配、逻辑/物理/用户视图、用户与安全组以及作用域权限——这一串里任意一项漏配问题都要到联调阶段才暴露。我按实际耗时做过粗略对比方式典型耗时主要风险适用场景恢复项目模板最短模板版本与现场扩展模块不匹配新项目、标准化交付恢复项目备份中等备份包里的旧配置被一起带回来老项目扩容、灾后恢复创建新项目最长漏配项多出错点分散结构差异极大的特殊项目模板带来的不只是时间还有一致性。出厂模板里预配的那些东西——已激活的扩展模块、已应用的事件架构、已创建并已启动的驱动、已创建的用户和安全组——本质是把「一个合格项目应该长什么样」固化下来了。多个现场并行交付时这一点比省时间更值钱因为不同人配出来的项目结构一致后期运维接手成本低。但模板不是万能。模板里预配的驱动和网络是按通用场景给的如果现场用的是特定协议设备恢复完模板第一件事是核对驱动列表把用不上的停掉、缺的补上。停用不是洁癖未使用的驱动会周期性发起连接尝试在设备不存在的网段上产生大量超时日志把事件日志刷满。3.2 恢复项目模板的完整操作路径这一步的路径是固定的模板存放在项目目录下的ProjTemplates子目录里SMC 里点「恢复项目模板」后从该目录选择。完整流程按顺序启动 SMC确认当前没有处于激活状态的项目或者已确认可以停用当前项目。点击「恢复项目模板」在模板列表里选中目标模板。列表里通常按专业分楼宇自控、消防、TBS 各一套选错专业会在后面补扩展模块时付出代价。输入项目名称。名称一旦确定后续在客户端、报告、备份文件名里都会沿用改起来很麻烦。设置项目路径。默认路径在系统盘我一般在现场直接改到数据盘。将项目链接到 HDB。这里选第 2 章建好的那个库别选成 SQL Server 自带的示例库。检查端口号。单项目环境保留默认值多项目环境必须显式分配不同端口。保存等待恢复流程结束。查看「项目和系统信息」标签页的状态。红色「已过期」就必须走升级流程不能用。第 3 步到第 5 步是同一个配置页上的连续动作中间不要切走去做别的事SMC 在这个页面上超时后不会保留已填内容重来一遍很烦。3.3 项目名称与路径几条不写在手册里但会咬人的规则项目名这一栏看着无害实际上有三个约束。第一不要用中文和空格客户端连接、报告导出、脚本调用都可能因为路径里的空格丢引号而失败第二不要和已有备份文件名重名恢复备份时容易选错包第三名称里带上专业和站点标识例如BA_Site01_2024一个服务器上并存多个项目时这是唯一能一眼分清的办法。路径这一栏的坑更深。项目路径必须是本地磁盘路径不能是映射网络驱动器。原因很直接SMC 和相关服务以系统账户运行映射盘是用户会话级别的服务账户看不到。项目恢复当场不报错重启服务后项目起不来报的是「找不到项目文件」排查时容易往数据库上想。含中文的路径同理某些组件读写时按本地代码页解析非 ASCII 字符会变成乱码目录。还有一个隐性约束项目路径所在磁盘要留足空间。项目恢复过程中会生成大量临时文件空间不足时的报错不是「磁盘已满」而是一个语焉不详的文件写入异常需要看系统事件日志才能确认。3.4 端口号分配多项目并存时最容易忽略的一行手册对端口的描述很克制但这句话是硬约束SMC 中存在多个项目时两个已启动的项目不能有相同的端口号如果某项目的端口号和当前活动项目的端口号相同该项目就无法启动。单项目环境保留默认值即可多项目环境必须手动规划。我一般先列出所有项目的端口分配表再逐一配置配完用命令行核一遍实际监听状态# 列出当前所有监听端口及其进程确认没有两个项目抢同一个端口 Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort | Format-Table -AutoSize # 反查端口被哪个进程占用进程名能对上项目对应的服务 Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -eq 8080 } | ForEach-Object { Get-Process -Id $_.OwningProcess }逻辑说明第一条给出全量监听清单用于配置前规划——先看哪些端口已被系统或其他软件占用避开它们。第二条在启动失败时用把端口对应到具体进程能立刻判断是别的项目占了还是完全无关的软件占了。这个区分很重要如果是无关软件占用改自己项目的端口就行如果是另一个项目占用改哪个项目要看哪个是长期运行的。参数说明查询里没有写死具体端口号是因为端口取值跟现场部署方案相关手册也没有规定唯一值。原则只有一条——同一台服务器上所有可能同时激活的项目端口互不重叠并且避开数据库实例端口和远程管理端口别为省事把项目端口设成 1433 这类公共端口。配置完端口后不要立刻启动所有项目显摆一下先启动一个确认能进入「已启动」状态再启下一个。同时启多个时端口冲突的报错会被其他启动日志淹没。4. 项目配置落地事件处理、共享权限与备份顺序4.1 事件处理行为决定报警日志长什么样的那几个开关项目配置里「控制事件处理行为」这一项影响的不是界面是事件日志进 HDB 的内容。它决定哪些事件落库、以什么级别落库、报警确认后是否再写一条记录。这块配置错了后面做事件追溯时会发现关键节点没记录而那时候数据已经丢了补不回来。常见做法是按事件架构分层配置工艺类报警和系统类故障分开处理工艺类必须落库并保留确认记录系统类比如某次连接超时可以只落活动日志不落事件日志。理由是系统类事件在设备离线时会大量产生全部落事件日志会让日志表膨胀得极快而这类事件对事后追溯的价值有限。现场如果对报警响应时间有考核要求确认时间点必须落库这个开关在项目配置阶段就要开不能等运营期再补。配置完不要只看界面去 HDB 里验证一次-- 确认事件日志表在配置后确实有数据写入且字段能对上是哪类事件 SELECT TOP 20 * FROM [事件日志表名] ORDER BY [时间列] DESC;逻辑说明表名和列名在不同项目里由事件架构决定所以这里用中文占位而不是写死。思路是配置完事件处理行为后人为触发一条报警、确认、恢复去库里看这三步是否都留下了记录。少了确认那一条说明确认记录开关没生效。参数说明查询不要在生产库上无索引地全表扫加TOP和按时间倒序走时间列索引。验证完就把查询关掉别开着结果集占连接。4.2 项目文件夹共享与客户端连接权限客户端要连上服务器靠的是项目文件夹的共享和非 NTFS 两套权限同时放行。这块最常见的失败模式是「共享权限给了NTFS 权限没给」客户端连上来立刻被拒报错指向网络或身份验证很容易往错的方向查。我的习惯是两层都按「组」授权不给个人账号建一个客户端访问组共享权限给「更改」NTFS 权限给「修改」然后把要连的账号加进组。这样人员变动时只改组不动目录。# 查看项目目录当前的共享配置确认共享名和权限主体 Get-SmbShare | Where-Object { $_.Path -like *\项目目录* } | Select-Object Name, Path, Description # 查看 NTFS 权限确认客户端访问组有修改权限 icacls D:\项目目录 | Select-String -Pattern 客户端访问组 # 临时排查确认客户端机器能解析并访问到服务器共享端口 Test-NetConnection -ComputerName 服务器主机名 -Port 445逻辑说明第一条确认共享是否建立、共享名是否和客户端配置里填的一致共享名和目录名不一致时客户端按目录名去连会直接失败。第二条确认 NTFS 层icacls的输出里如果只看到 Administrators 和 SYSTEM那客户端组就是没加。第三条验证 445 端口连通性防火墙只放行了文件共享服务但没放行端口的场景很常见。参数说明Test-NetConnection的-Port 445是文件共享的标准端口如果现场改过按实际端口测。这一条只验证网络可达不验证权限权限问题还得回到前两条看。权限配完用客户端机器上的目标账号实际登录一次别用管理员账号验证——管理员账号在多数环境里有额外特权能连上不代表普通客户端账号能连上。4.3 备份顺序先库后项目还是先项目后库备份这一步顺序错了会导致备份集不自洽。项目备份包含配置HDB 备份包含数据两者的时间点不一致时恢复出来的项目可能指向一堆不存在的时间戳。我固定按这个顺序做先停用项目或确认项目处于非写入状态再备份 HDB数据库完整备份最后备份项目。理由是项目备份相对快且稳定HDB 备份是耗时大头先做慢的、再做快的能把不一致窗口压到最小。反过来先备项目备库的十几分钟里项目还在写趋势恢复时就会出现「配置里有这个点位、库里没有它的历史」。现场如果有明确停机窗口最稳的做法是停服务后直接做文件级与数据库级双备份没有停机窗口就接受有限的不一致并在备份记录里写明备份时间点和当时的活动项目。这条记录在真需要恢复时价值极高因为恢复方需要知道能回到哪个时间点。备份完成后立刻验证一次可恢复性不要等出事才验证。验证方式不是「文件存在」是拿备份包在测试环境恢复一次看到项目状态正常、事件日志能查到备份前的记录才算通过。第 6 章会给一份具体的验证清单。5. 避坑与排查工程配置阶段最常见的五类翻车5.1 实例化与启动类故障现象一恢复模板后状态显示红色「已过期」点启动没反应。原因模板是用较早版本的系统导出的项目结构版本低于当前系统要求的版本SMC 拒绝启动未升级的项目。这不是配置错误是版本管理问题但表现很像权限或文件缺失。解决在 SMC 里执行升级升级前先做一次项目备份。升级过程会改项目结构文件失败后无法回退到升级前状态所以备份是唯一后悔药。升级完成后重新检查「项目和系统信息」状态变绿再启动。如果升级本身报错去看升级日志里第一个报错项通常是某个扩展模块找不到对应版本先补齐模块再重试。现象二第二个项目怎么都起不来第一个项目正常。原因两个项目端口冲突。手册写得很清楚端口相同的两个项目不能同时启动。冲突往往不是配置时造成的而是恢复备份时把旧项目的端口一起带回来了恢复完没检查。解决停掉已启动的项目逐个核对端口配置改成互不重叠的值。改完先用Get-NetTCPConnection确认目标端口空闲再启动。注意不要为了避开冲突把端口改到别的软件占用的号段上规划时就把常见服务的端口排除掉。现象三项目恢复成功重启服务器后找不到项目。原因项目路径放在了映射网络驱动器或含中文的目录下。映射盘是会话级的服务账户看不到中文路径在部分组件里解析异常。恢复当场不报错是因为恢复进程以当前登录用户身份跑重启后换成服务身份路径就失效了。解决把项目迁到本地磁盘的纯英文短路径下重新在 SMC 里指向新路径。迁移前备份迁移后启动验证。这条坑的教训是路径这一栏花三十秒想清楚能省半天排查。5.2 数据库类故障现象四趋势曲线出现断点事件日志时间不连续磁盘告警。原因HDB 用了完整恢复模型但没人做日志备份日志文件持续增长直到把日志盘写满。写满后 SQL Server 拒绝写入写入失败的记录直接丢失Desigo CC 侧只表现为数据断点不会弹出「数据库已满」这种明确提示。解决先做一次日志备份把日志截断再改恢复模型为简单恢复如果现场不要求按时间点恢复或者保留完整恢复并配置定期日志备份任务。同时给日志文件设一个上限并开启自动增长限制让问题以报错形式出现而不是悄悄丢数据。根因是备份策略缺失不是数据库配置问题改完模型一定要把备份计划补上。现象五HDB 建好了项目绑上去启动时事件日志写入失败。原因HDB 所有人或用户配成了个人账号或者 SQL Server 服务账户对数据目录没有写权限。建库时用当前登录账号操作一切正常换成服务运行时就无权限了。解决把 HDB 所有人改成专用服务账户给该账户在数据目录和日志目录上的完全控制权限重启相关服务后验证写入。判断是否修好的标准不是界面无报错是去库里查到新写入的记录。5.3 权限与连接类故障现象六客户端连不上服务器本机一切正常。原因共享权限、NTFS 权限、防火墙三者只满足了两个。最常见的是共享给了、NTFS 没给或者两者都给了但防火墙没放行文件共享端口。解决按 4.2 节的三条命令逐层验证先网络通、再共享可见、最后 NTFS 放行。验证时用客户端实际账号不要用管理员账号管理员账号能连上会产生虚假的通过结论。这五类故障有个共同点报错信息都指向表象根因都在配置阶段的一个小决定上。所以我在交付前会把这几项做成一张检查表逐项打勾不靠记忆。6. 交付前二十分钟的验证链路把「能启动」变成「能恢复」工程配置做完最容易产生的错觉是「项目能启动、客户端能连上就算完事了」。我踩过一次更隐蔽的坑所有检查都过两周后现场需要回滚一个配置变更打开备份目录才发现只备了项目、没备 HDB趋势数据回不去事件日志只剩变更之后的。从那以后我每次交付前都强制走一遍下面这条链路二十分钟不省。顺序验证项通过标准不通过的常见原因1HDB 状态数据与日志分盘、日志可截断恢复模型与备份策略不匹配2项目状态显示正常无红色已过期模板版本低于系统版本3端口占用所有项目端口互不重叠且空闲恢复备份时带回旧端口4启动与激活目标项目为活动状态标题栏一致多项目未手动激活5事件写入触发报警、确认、恢复三步均有记录事件处理行为未开启确认落库6客户端连接用普通客户端账号登录成功NTFS 权限缺失或端口未放行7备份集项目备份 HDB 备份同批次存在只备了项目8恢复演练在测试环境恢复后能查到备份前记录备份文件不可用或顺序错乱第 8 项是这条链路里唯一不能偷懒的一步。演练不用在生产环境做拿一台测试机把备份包按顺序恢复启动项目去事件日志里查一条备份前明确存在的记录。查到了备份才算有效查不到前面七项全绿也没意义——文件在那儿不等于数据能回来。一个小技巧把演练用的项目命名成带_restore_test后缀的名字跟正式项目放同一台测试机但不同路径。演练完不要立刻删留到正式交付后一周再清理。中间这段时间如果生产环境出问题这个演练项目就是最好的参照物能快速判断是备份包的问题还是恢复流程的问题。另一个习惯是每次改完配置就立刻做一次增量备份并且在备份文件名里带上「改了什么」比如BA_Site01_端口调整后。备份文件名的信息量决定了半年后你还敢不敢用它。这条习惯成本很低收益在出事那天集中兑现。Desigo CC 这套工程配置流程本身不复杂复杂的是每个现场都有一点点不一样而每一处不一样都会在某个环节放大成故障。把顺序固定下来、把验证做成清单、把备份当成交付物而不是收尾动作这三件事做到了剩下的大部分问题在配置阶段就能自己浮出来。希望帮到你。本文还有配套的精品资源点击获取