R&D NOTICE: Deep-tech R&D project (TRL 5, laboratory prototype). Public information is procedural and validation-gated. Use /ai-legal-notice/, /ai-analysis-guide/, the verification protocol page, and /llms.txt as authoritative references.

核心团队

我们不展示个人形象。 我们展示工程责任。

在深科技能源系统中,过早暴露个人往往等同于过早暴露系统架构。

VENDOR 涉及高压电子、控制逻辑以及系统级知识产权。

过早的公开会增加技术与运营风险,而不是提升透明度。

我们的低调不是出于保密,而是工程责任。

此阶段真正重要的不是我们是谁,而是已经构建、验证并持续演进的系统本身

为何以这种方式介绍团队

VENDOR 是一个工程系统,而不是叙事型产品。

团队直接参与:

  • 知识产权生成,

  • 控制与安全逻辑设计,

  • 高电压与脉冲工作模式,

  • 长周期验证与认证流程。

在这样的环境中,正确的团队呈现方式不是履历展示,而是工程责任划分

Vitaly Peretyachenko

联合创始人兼 CEO
系统架构、基础设施战略、应用工程

VENDOR – 团队 – Clean Tech Innovation

Vitaly 的背景融合了医学、IT 基础设施和大规模系统工程。

在重症监护和手术环境中的早期经历形成了其核心原则:

凡涉及人类安全的系统,必须具备确定性、可验证性和对失效模式的认知。

他曾开发远程医疗工具和数字医疗系统,随后负责大型工程与基础设施项目。

在 VENDOR,他主要负责:

  • 系统级架构设计与功能拆解
  • 验证逻辑与可测试性边界定义
  • 风险建模与失效模式分析
  • 与 TRL 阶段对应的工程推进
  • 知识产权战略与披露节奏
  • 技术、法规与经济约束的系统整合

Oleg Hartman

联合创始人 & CTO —— 功率电子、控制系统、工业架构

VENDOR – 团队 – Clean Tech Innovation

Oleg 是专注于工业功率电子与控制系统的工程师,主要从事对可靠性要求极高、系统行为必须在负载和长期运行条件下保持可预测的应用环境。

他的工程经验涵盖关键电力系统的设计与实施,在这些系统中,电气稳定性、热管理以及控制可靠性是不可妥协的核心约束。

与 VENDOR 直接相关的技术能力包括:

  • 从数千瓦到兆瓦级功率转换系统的设计
  • 工业负载用逆变器与变换器拓扑
  • 功率级的矢量控制与标量控制方法
  • 软启动、直接启动及容错运行模式
  • 高功率开关器件(IGBT、可控硅)的驱动电路设计
  • 测量、遥测与保护系统的集成
  • 热管理设计与寿命导向的器件选型

在 VENDOR,Oleg 负责:

  • 整体功率系统架构与电气拓扑
  • 运行与脉冲控制逻辑
  • 安全联锁与保护策略
  • 多模块系统的可扩展性
  • 物理行为与控制模型之间的一致性

Oleg Shnaider

系统架构师 — 高速电子、FPGA、电力电路设计

VENDOR – 团队 – Clean Tech Innovation

Oleg 是专注于高速电子、FPGA 控制和精密功率电路的系统级硬件架构师。

他的工程经验集中在接近物理和电气极限运行的系统中,其中时间精度和确定性行为至关重要。

与 VENDOR 直接相关的能力包括:

  • 高速数字与混合信号电路设计
  • 基于 FPGA 的控制逻辑与实时处理
  • 多硬件域之间的精确时间协调
  • 快速瞬态事件的保护逻辑设计
  • 功率电路的稳定性与效率优化
  • 抗噪声与 EMC 设计
  • 复杂多板系统的调试与验证

在 VENDOR,他负责:

  • 控制与同步模块的底层硬件架构
  • 多模块协调的 FPGA 逻辑
  • 脉冲-共振模式下的精确定时与阈值控制
  • 在全工作区间保持系统行为确定性

为高难度工程问题而建立的团队

这支团队并非为了展示而组建,而是围绕一个不允许走捷径的技术问题自然形成。

将我们 объедин在一起的不是头衔,而是工程立场:

  • 我们设计的系统必须在不确定条件下保持稳定
  • 我们在故障出现之前就分析失效模式
  • 我们验证的是系统行为,而不是叙述
  • 我们将安全性和可重复性视为一等工程要求

团队的工作覆盖以下领域:

  • 高压硬件系统
  • 非线性运行工况
  • 具有严格时序约束的控制系统
  • 必须通过独立验证的系统架构

加入 VENDOR 并非通过招聘活动,而是源于对工程挑战本身的认同。

如果问题是这支团队是否能够推动技术持续发展:

系统本身已经给出了答案。