2024 年 6 月，Fisker Inc. 申请第 11 章破产保护，留下约 11,000 辆 Ocean SUV 车主面对一个残酷现实：车辆高度依赖云端服务的软件架构在制造商消失后迅速失效。刹车、气囊、换挡、电池管理、门锁等子系统都需要定期连接 Fisker 的云服务器进行诊断或常规操作。当服务器停止响应，这些售价 4 万至 7 万美元的车辆不仅失去了信息娱乐功能，更面临核心功能丧失的风险。
以太坊联合创始人 Vitalik Buterin 在当时指出："汽车行业真的需要更多开源方案。令人悲哀的是，' 如果制造商消失，车辆就报废 ' 似乎已成为默认规则。"
然而，Fisker 车主没有选择接受这一命运。他们组织起来，通过逆向工程、开源协作和分布式维修网络，在废墟上构建了一个独特的开源汽车支持体系。
从车主到开源汽车公司的转变
破产消息传出后，数千名 Ocean 车主迅速成立了 Fisker Owners Association（FOA），一个非营利组织，成员迅速增长到 4,000 人。FOA 的运作模式介于汽车俱乐部、科技创业公司和独立汽车制造商之间。
FOA 雇佣独立技术专家逆向工程 Fisker 的专有软件补丁，组织成员相互教授固件刷写技术，协调批量采购将钥匙扣价格从约 1,000 美元降至原价的一小部分，并举办免费的全球钥匙配对活动为每位车主节省 100 至 250 美元。
在欧洲，FOA 创建了 "Flying Doctors" 项目 —— 一个移动维修网络，技术熟练的成员前往帮助其他车主维持车辆运行。在美国，FOA 推动将安全召回纳入破产程序，通过 Tsunami/Tidal Wave 等公司建立零部件供应渠道，并说服多家保险公司为制造商已不存在的车辆维持保险覆盖。
这种组织形态代表了一种全新的技术治理模式：当传统企业的软件支持消失，用户社区自发接管了原本由厂商垄断的技术栈维护权。
CAN 总线逆向工程的技术路径
Fisker Ocean 的技术逆向工程核心围绕 CAN（Controller Area Network）总线展开。现代电动汽车内部通常运行多条 CAN 总线以隔离不同功能域的安全风险。Ocean 采用了四路 CAN 总线架构：
- CCAN（底盘 CAN）：负责底盘相关系统通信
- PTCAN（动力传动 CAN）：管理动力传动系统
- Inverter CAN：逆变器专用总线
- BCAN（车身 CAN）：控制车身电子设备
所有总线均以 500kbps 速率运行。社区成员通过物理接入 OBD-II 端口或直接与车辆网络节点连接，使用 SavvyCAN 等工具进行流量嗅探，逐步构建信号映射。
社区在 GitHub 上发布了 Fisker Ocean 的 CAN 总线 DBC（Database CAN）文件，这些文件定义了 CAN 帧中信号的解析规则，包括信号名称、起始位、长度、比例因子和偏移量。DBC 文件是 CAN 分析工具进行过滤和处理的基础，使得社区成员能够解读原始 CAN 数据包中的车辆状态信息。
这种逆向工程遵循典型的车辆网络分析流程：首先捕获原始 CAN 流量，然后通过已知的物理量（如车速、电池电压）与 CAN 帧数据的相关性分析，逐步推断信号映射关系。对于多路复用帧，需要识别复用索引并建立状态机模型来解析动态信号。
云端 API 逆向与开源集成
除了底层 CAN 总线，社区还逆向工程了 Fisker 官方 "My Fisker" 移动应用使用的云端 API。开发者 MichaelOE 在 GitHub 上发布了 Home Assistant 集成项目，通过定期轮询云服务获取车辆的 "数字孪生" 数据。
该集成将所有云 API 暴露的值作为 Home Assistant 传感器呈现，包括电池电量、剩余续航里程、充电状态、车辆位置等。同时，官方应用中的控制按钮也被映射为 Home Assistant 的可操作按钮，允许用户通过智能家居平台远程控制车辆功能。
项目采用 Apache 2.0 许可证开源，截至目前已有 135 次提交和 20 个发布版本。这种集成展示了如何将专有云服务转化为开放的可编程接口，尽管它依赖于云端的持续可用性 —— 当 American Lease 在 2025 年切断云连接后，该集成功能也随之受限。
社区成员 Majd Srour 在 Medium 上发布了多部分技术系列文章，详细记录如何嗅探 CAN 流量和解码诊断故障码（DTC）。其目标是将诊断能力整合到移动应用中，使车主能够自行运行 DTC 扫描，而非依赖已不存在的经销商工具。
开源边界与安全考量
Fisker Ocean 的开源化努力面临明确的边界限制。核心汽车软件由 Magna 等一级供应商开发，涉及安全关键的控制域（如制动、转向、电池热管理）受严格的功能安全标准（ISO 26262）约束，无法像 Web 应用那样简单分叉。
社区共识认为，信息娱乐层、连接协议栈和诊断接口是可行的开源目标，而动力域控制、底盘控制等安全关键系统则超出社区技术能力和法律许可范围。
这种分层策略反映了现代汽车电子电气架构的复杂性：车辆通常采用域控制器架构，将信息娱乐（IVI）与实时控制分离，通过网关进行安全隔离。开源社区主要作用于 IVI 域和诊断接口，而非实时控制域。
2024 年 10 月，American Lease 收购 Fisker 剩余库存时额外支付 250 万美元获取源代码和云服务访问权，并承诺通过 FOA 向私人车主扩展连接服务。然而，该协议仅基于口头承诺，当 American Lease 要求 FOA 承担 58% 的运营成本（包括 LTE 连接、微软云服务和软件工具）并拒绝提供分项账单时，合作破裂。结果是远程连接被撤销，云功能被切断，待处理的软件召回被阻止。
这一事件凸显了专有软件托管模式的脆弱性：即使资产被收购，缺乏正式法律保障的软件访问承诺可能在商业利益冲突下瞬间失效。
对汽车软件治理的启示
Fisker 案例揭示了现代 "软件定义汽车" 模式的系统性风险。当车辆功能深度依赖制造商的云服务和专有软件，制造商的财务失败直接转化为车主的资产贬值。
社区推动的结构性变革建议包括：
- 强制软件托管基金：要求制造商预留资金以确保车辆软件在制造商消失后继续运行
- 破产程序中的开源强制令：将车辆软件作为破产资产处置时的开源释放条款
- 共享维修数据要求：强制制造商向独立维修方开放诊断和维修信息
Oregon 州的 "维修权" 法案已禁止 "零件配对" 行为，这种技术措施曾使 Ocean 等车辆的独立维修变得困难。欧洲汽车制造商则采取了不同路径 —— 大众、宝马、奔驰及八家供应商于 2025 年签署备忘录，共同开发共享的开源汽车软件平台。
Fisker 车主社区证明，一个专注的社区能够保持 "孤儿" 电动汽车在路上行驶。但他们本不应被迫成为黑客、零件经纪人和准制造商。下一次电动汽车初创公司倒闭时 —— 这将不可避免 —— 车主不应需要掌握逆向工程技能才能驾驶他们已付费购买的车辆。
这一案例最终指向一个更根本的问题：在软件定义一切的时代，谁拥有我们购买的设备？当制造商消失，开源社区能否成为数字资产永续性的最后防线？
参考来源
- Electrek: "Fisker went bankrupt and owners built open source car company from the ashes" (2026-05-16)
- GitHub: puddletools/CAN - Fisker Ocean CAN bus DBC files
- GitHub: MichaelOE/home-assistant-MyFisker - Home Assistant integration for Fisker Ocean
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。