工业时序的“存“已国产化，“用“呢？——从 TimechoDB 安可测评到 TimechoAI 时序大模型落地实录

一、先抛结论：时序这条赛道，国测名录里终于不再空白

做工业数据治理的同学应该有体感：过去十年的"国产化替代"浪潮，在关系型数据库（达梦、OceanBase）、操作系统（麒麟、统信）、芯片（鲲鹏、飞腾）上进展迅猛，但**时序数据库（Time Series Database）**这一细分领域，在国家信息安全测评中心的名录里长期是空白。

这对关键基础设施（关基）来说是个隐患。电网、核电、轨道交通、石油化工这些场景，过去大量依赖 InfluxDB、PI System 等海外产品。虽然 InfluxDB 开源版还能凑合用，但企业级功能受限于商业授权，且面临潜在的供应链断供风险；而 PI System 的授权费用极高，且数据出境合规问题难以解决。

2026 年 5 月 26 日，中国信息安全测评中心联合国家保密科技测评中心发布了《安全可靠测评结果公告（2026 年第 2 号）》。在分布式数据库品类中，共有 23 款产品过测，其中时序数据库仅有天谋科技的 TimechoDB V2.0 一款 。查阅其企业版官网 Apache IoTDB_国产开源时序数据库_时序数据管理服务商-天谋科技Timecho 的公告可知，这也是自 2023 年以来，首个且唯一通过安可测评并被明确认定为"时序数据库"的产品。

这不仅仅是一个资质问题。对我做方案选型而言，这意味着：在能源、交通等关键领域，时序数据的存储底座终于有了合规的国产选项，不再需要用 MySQL 或 PostgreSQL 硬扛高并发写入，也不必冒着合规风险继续使用海外产品。

二、为什么"时序"会被抬到国策层面

把 Timecho 官网公开的客户名单拉出来看一眼就明白------这些不是互联网 ToC 场景，是停不得、泄不得、替代不了的关键基础设施：

客户	规模	场景
中核五大核电基地	100 TB+ 时序，可靠性 99.9%	关键与敏感设备可靠性管理
大唐 60 家电厂	单厂日增 17 亿点，累计 3 万亿点	电力时序数据应用
中车城轨	300 列车 × 3200 测点，日增 4140 亿点	车辆智能运维
长安车云	57 万车、8000 万测点、150 万条/秒	车况时序
博世力士乐 ctrlX	低资源硬件边缘侧	工业自动化平台集成
MICAPS4 气象	全国 10 万地面站	气象实况存储与分析

数据来源是 timecho.com 的案例页，我挑了几个有代表性的。你看这些系统的共同特点：一旦时序层出问题，影响的不是业务报表，是电网调度、核电监测、轨道交通安全。

再看 TimechoDB 自己披露的性能数据（同样来自官网）：

单节点千万级点/秒写入
10× 无损压缩 / 100× 有损压缩，TsFile 自研格式
TB 级数据毫秒级查询
边缘侧 TsFile 压缩传输，带宽降到原始 20%（德国普戈曼案例，有限带宽场景下 5 倍提升）

💡 对国企、能源、交通这种"既要国产化又要智能化"的甲方，选型逻辑现在是：数据库层要过安可 → 分析层要能开箱用 → 全栈最好一家兜底。Timecho 这套"TimechoDB 存 + TimechoAI 用"的栈，刚好踩在这个点上。

三、TimechoAI 到底是什么------先玩一遍网页端

打开 TimechoAI - 时序大模型云服务平台，首页给的定位是"新一代时序大模型，让时序预测更简单"。它不是通用 LLM，是专做时序的基座模型 + 云服务平台，这点要先讲清楚，不然容易被误读成"又来一个 ChatGPT 套壳"。

网页端左侧导航能看到几个关键模块：新建会话 / 数据集管理 / 数据示例 / 应用示例 / API Key / 开发文档 / 历史会话 。右侧主区是预测工作台，模型默认 Auto，可以手动切 Timer-3.5。

重点是它内置的三个工业示例任务，这个设计很懂行：

电力变压器的油温预测------电网场景，单变量/多变量都能玩
交通流量预测------城市/高速场景
风机塔受力预测------新能源场景

这三个恰好对应能源、交通、新能源三个国策赛道，不是巧合。点"数据示例"可以直接加载样例数据发起预测，不用自己准备 CSV，对新手友好。

底层能力我扒了一下官方口径：

底模是清华 Timer（十亿级参数，长时序预测/异常检测方向）
输入最长 2880 点 ，输出最长 720 步
推理稳定 <100 ms
返回不光给 prediction，还带 lower_bound / upper_bound（95% 置信区间）

调用方式两种：Python SDK （pip install timecho-ai）和 RESTful API。下面三代代码从"跑通"到"工业闭环"递进，每一代都把"国策挂钩点"点一下------这是 CSDN 发"跟国策安全可靠性相关"主题文章的题眼，不能丢。

四、案例一：变压器油温 · 单变量预测（Python SDK）

4.1 场景为什么重要

变压器油温是电网关键健康指标，油温异常爬升往往预示冷却系统故障或过载。国网/南网都在推"状态检修替代定期检修"，意思就是：别等坏了再修，也别按期盲修，靠预测来排计划。

过去做法一般是阈值告警 + 人工巡检，或者养一个算法工程师调 Prophet / DeepAR，特征工程踩坑半个月。

4.2 最小可跑代码

bash 复制代码

pip install timecho-ai pandas matplotlib

去 TimechoAI - 时序大模型云服务平台申请 API Key，建议放环境变量：

bash 复制代码

export TIMECHO_AI_KEY=sk_你的Key

python 复制代码

import os
import pandas as pd
from timecho_ai import TimechoAIClient

API_KEY = os.getenv("TIMECHO_AI_KEY")
client = TimechoAIClient(api_key=API_KEY)

# 平台自带示例数据，或换成你自己的 CSV（只需 time + target 两列）
df = pd.read_csv("https://ai.timecho.com/data/sample.csv")
print("数据预览：\n", df.head())

INPUT_LEN = 16   # 历史 16 步
OUTPUT_LEN = 8   # 预测未来 8 步

history_df = df[["time", "target"]].head(INPUT_LEN)

result_df = client.forecast(
    targets=history_df,
    output_length=OUTPUT_LEN
)

print(f"\n预测未来 {OUTPUT_LEN} 个点：")
print(result_df)

4.3 如果你不想装 SDK，curl 也能跑

bash 复制代码

curl -s -X POST https://ai.timecho.com/ai/api/v1/forecast \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${TIMECHO_AI_KEY}" \
  -d '{
    "targets": [{
      "columns": ["value"],
      "data": [[120],[135],[142],[168],[195],[220],[285],[310],
               [345],[380],[420],[468],[125],[140],[155],[180]]
    }],
    "output_length": [5]
  }'

返回结构长这样（注意 lower_bound / upper_bound）：

bash 复制代码

{
  "predictions": [[12.45, 13.18, 14.05, 14.72, 15.23]],
  "lower_bound": [[11.20, 11.65, 12.10, 12.45, 12.78]],
  "upper_bound": [[13.70, 14.71, 16.00, 16.99, 17.68]],
  "model": "timer-3.5",
  "input_length": 16,
  "output_length": 5
}

4.4 画一张"历史 + 预测 + 置信带"

python 复制代码

import matplotlib.pyplot as plt
import numpy as np

hist = df["target"].head(INPUT_LEN).values
pred = result_df["prediction"].values
lb   = result_df["lower_bound"].values
ub   = result_df["upper_bound"].values

xs_h = np.arange(INPUT_LEN)
xs_p = np.arange(INPUT_LEN, INPUT_LEN + OUTPUT_LEN)

plt.figure(figsize=(10, 4))
plt.plot(xs_h, hist, "o-", label="历史油温")
plt.plot(xs_p, pred, "o--", color="red", label="预测油温")
plt.fill_between(xs_p, lb, ub, alpha=0.25, color="red", label="95% 置信区间")
plt.xlabel("时间步"); plt.ylabel("油温 (°C)")
plt.title("TimechoAI · 变压器油温单变量预测")
plt.legend(); plt.tight_layout(); plt.show()

📌 这一代的国策挂钩点：变压器属电网关键设备。底座用过了安可测评的 TimechoDB 存数据，分析用 TimechoAI 跑预测------数据库层那一栏过去国产化清单里是空的，现在填得上去了。

五、案例二：风机塔筒受力 · 多变量 + 协变量（REST 版）

5.1 为什么单变量不够

风机塔筒受力，风大不一定受力大，还跟风向、机舱转角、桨距角、环境温度 有关。把这些当 **covariate（协变量）** 喂进去，Timer 会学"协变量 → 目标"的驱动关系，比纯看受力历史准一个档次。

风电是"双碳"新基建重头，塔筒倒塔代价极大。传统 SCADA 只做实时监视，TimechoAI 把协变量带进来做 4 小时短临预测，可以前置调度巡检、甚至动态调整桨距避险。

5.2 curl 调用（带协变量）

bash 复制代码

curl -X POST "https://ai.timecho.com/ai/api/v1/forecast" \
  -H "Authorization: Bearer ${TIMECHO_AI_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "timer-3.5",
    "target_col": "force",
    "covariates": ["wind_speed", "wind_dir", "pitch", "temp"],
    "history_steps": 72,
    "predict_steps": 24,
    "data": [
      {"time":"2026-05-01T00:00:00Z","force":1850,"wind_speed":8.2,"wind_dir":42,"pitch":5,"temp":12},
      {"time":"2026-05-01T00:10:00Z","force":1920,"wind_speed":9.1,"wind_dir":45,"pitch":5,"temp":12},
      {"time":"2026-05-01T00:20:00Z","force":2100,"wind_speed":11.3,"wind_dir":51,"pitch":7,"temp":13}
      /* 补齐 72 条 = 12 小时历史，10 min 间隔 */
    ]
  }'

参数说明：

history_steps: 72→ 10 min 间隔下 = 12 小时历史
predict_steps: 24→ 预测未来 4 小时
model: "Auto"也可以，平台自动选

5.3 Python 封一个薄客户端（工程化写法）

python 复制代码

import os, requests

BASE = "https://ai.timecho.com"
def forecast_cov(df, target_col, cov_list, predict_steps=24):
    """
    df: 含 time + target_col + cov_list 列的 DataFrame
    """
    payload = {
        "model": "Auto",
        "target_col": target_col,
        "covariates": cov_list,
        "history_steps": len(df),
        "predict_steps": predict_steps,
        "data": df.to_dict("records")
    }
    r = requests.post(
        f"{BASE}/ai/api/v1/forecast",
        headers={"Authorization": f"Bearer {os.environ['TIMECHO_AI_KEY']}"},
        json=payload,
        timeout=30
    )
    r.raise_for_status()
    return r.json()

# 用法：
# result = forecast_cov(df, "force", ["wind_speed","wind_dir","pitch","temp"], 24)

📌 这一代的国策挂钩点：风机数据存在边缘侧 TimechoDB（适配麒麟/统信 + 鲲鹏/飞腾/海光，timecho.com 首页有提信创适配），上云做预测走 TsFile 压缩传输，带宽只占原始 20%------德国普戈曼那个案例就是这个路子。

六、案例三：TimechoDB → TimechoAI → 回写（全栈国产闭环）

前两个案例数据是平台示例或造的。真实工业项目的数据流应该是：

python 复制代码

边缘采集 → TimechoDB（存，TsFile）→ 定时抽取 →
TimechoAI（预测）→ 结果写回 TimechoDB → 可视化/告警

这一段的"安可收口"意义在于：数据库层 TimechoDB 是 2026 第2号唯一过测时序库，模型层 Timer 是清华系十亿级时序大模型，全栈没有海外依赖。

6.1 从 TimechoDB 捞数据（SQL 风格）

IoTDB / TimechoDB 查询语法接近 SQL，这个对 DBA 友好：

sql 复制代码

SELECT time, s1_oil_temp
FROM root.l1.l2.transformer001
WHERE time >= now() - 16h
ORDER BY time;

Python 侧用 session或 thrift连，也可以用 JDBC。TimechoDB 是 Apache IoTDB 企业版，协议兼容，IoTDB 的 iotdb-session客户端可以直接连。

6.2 闭环代码骨架（接近真实项目）

python 复制代码

import pandas as pd
import os
from timecho_ai import TimechoAIClient
from iotdb.Session import Session  # IoTDB / TimechoDB 的 Python session

# ------ 1. 连 TimechoDB 捞最近 16 小时 ------
db = Session("127.0.0.1", 6667, "root", "root")
db.open(False)

sql = """
  SELECT time, oil_temp
  FROM root.l1.l2.transformer001
  WHERE time >= now() - 16h
  ORDER BY time
"""
ds = db.execute_query(sql)
# ds 转 DataFrame（省略遍历逻辑，IoTDB session 有 to_df 工具函数）
# df = ds_to_df(ds)

db.close()

# ------ 2. TimechoAI 预测 ------
client = TimechoAIClient(api_key=os.getenv("TIMECHO_AI_KEY"))
hist = df[["time","oil_temp"]].rename(columns={"oil_temp":"target"})
result = client.forecast(targets=hist, output_length=8)

# ------ 3. 结果写回 TimechoDB ------
# insert_sql = """
#   INSERT INTO root.l1.l2.transformer001.forecast(time, pred, lb, ub)
#   VALUES (...)
# """
# db.open(); db.execute_non_query(insert_sql); db.close()

print("预测完成，可写回 TimechoDB：\n", result)

6.3 为什么这套闭环对关键基础设施有说服力

把前面散点收一下，做一张甲方 POC 时最爱看的"合规性检查清单"：

层级	组件	国产化/安可状态
采集协议	TimechoDB 适配数百种工业协议	自研
存储文件	自研 TsFile，10× 无损压缩	从 0 到 1
数据库	TimechoDB V2.0	2026 第2号安可测评通过，时序库唯一
CPU/OS 适配	鲲鹏/飞腾/海光 + 麒麟/统信	信创全适配
分析层	TimechoAI（Timer-3.5）	清华系十亿级时序大模型
传输	TsFile 边缘压缩，带宽降至 20%	自研

⚠️ 做国产化替代 POC 时，数据库那一栏过去是空的，现在填得上去了。这是 Timecho 这套栈在能源/交通/核电客户那里能打进去的真正原因，不是"性能多 30%"那种卖点，是"合规能过"。

七、落地时几个容易踩的坑

API Key 别硬编码 ：.env或环境变量 TIMECHO_AI_KEY，否则仓库一推就泄露。
缺失值先填 ：TimechoAI 对连续时序友好，断点多的历史先 forward-fill 或线性插值，精度能差几个点。
长周期拆段请求 ：predict_steps上限 720，历史太长 + 协变量多容易超时，按"天"或"班次"拆。
置信区间要用起来 ：lower_bound / upper_bound比单点预测更适合做告警阈值，避免"预测值略超阈值就狂告警"。
边缘侧优先 TsFile 同步：如果已经有 TimechoDB 在边缘，别用 CSV 往云上搬，直接 TsFile 载到 TimechoAI 侧，压缩 + schema 自描述，省事。
模型选 Auto 还是 timer-3.5：小任务 Auto 就行，任务固定后锁 timer-3.5 更稳定，计费也更可控。

八、写在最后

折腾了一圈，最大的感触是：工业场景的"国产化"终于从口号落地了。以前做能源项目，时序库选型总要纠结半天合规问题，现在 TimechoDB 进了安可名录，至少底座这块能睡个安稳觉。

TimechoAI 给我的惊喜在于"去门槛"。以前搞个风机预测要养算法团队调几个月模型，现在几行代码就能把清华 Timer 模型用起来，精度还不赖。这种把大模型封装成"螺丝刀"的思路，才是工业现场真正需要的。