本文涵盖以下主题：
开发选项
开发KNX设备有三种不同的方法：
完全发展
成本：
低
推向市场时间：
慢
描述:
制造商选择从头开始开发整个 KNX 产品。 这意味着其开发的唯一基础是 KNX 规范以及产品的所有部分：即 物理层、通信协议栈、应用程序，需要从零开始开发和认证。 此选项不允许快速上市推广，但它具有制造商完全独立的优势。 因此，此选项最适合具有足够开发能力并瞄准大批量生产的公司。
所需的努力：
硬件工程、软件开发、测试和管理。
部分开发
成本：
中等
推向市场时间：
相对快速
描述:
此选项最适合以 KNX 会员身份开始的公司，因为它允许基于可用且已通过 KNX 认证的系统组件和/或 KNX 认证的通信协议栈，或 KNX 认证的模块包括（KNX 认证）应用程序开发新产品。 这样，开发的“最坏情况”仅限于应用程序的开发。 此外，认证在“最坏情况”下仅限于应用程序。 KNX 甚至提供了一个开发指南（参见登录后可用的 MyKNX 中的“下载”），其中包含基于 KNX 认证的系统组件的示例。 开发指南是 KNX 标准（第 2 卷）的一部分。
所需的努力：
部分硬件工程& 软件开发。 简化的测试和（更少的）管理工作。
购置OEM设备
成本：
高
推向市场时间：
快速
描述:
制造商选择重新标记由另一个 KNX 成员开发的已认证 KNX 设备。 使用此选项，开发工作几乎减少到零，只需以转售制造商的名义注册应用程序。 这是一个纯粹的管理程序，因此不需要对设备进行任何（重新）测试。
所需的努力：
行政工作
建议的步骤
第 1 步：选择配置文件（KNX 规范，第 6 卷）
描述:
KNX 规范预设了大量设备功能，这些功能由于兼容性/可管理性被“分组”到许多 KNX 系统配置文件中，这些配置文件决定了运行期功能和设备配置方式（通过例如 ETS）。 这些配置文件在 KNX 规范的第 6 卷中进行了描述。 即: 根据所需的设备功能及其配置方式，应选择适当的配置文件，这也将确定可用于开发通信协议栈的微控制器的类型。
第二步：根据KNX介质选择系统组件
描述:
一旦配置文件被固定，设备硬件的开发就可以开始了，需要做出的决定是设备通信所需 的KNX 介质：双绞线、电力线、无线或 IP。 选择的 KNX 介质类型决定了可用于开发设备硬件的系统组件类型。
第 3 步：开发应用程序（ETS 产品入口）
描述:
一旦设备硬件准备就绪，就可以开发称为“应用程序”的软件。 这样的应用程序通常会由 ETS 加载到设备中。 为了生成在 ETS 中可用的应用程序，即创建它的“ETS 产品条目”，需要用到另一个工具。 该工具称为“KNX 制造商工具”，KNX 成员可以通过 MyKNX 检索该工具。 由于 ETS 处理的任何设备都应提交 KNX 认证，因此强烈建议在开发过程中为认证测试准备适当的输入。 为此，KNX 成员可以使用另一个工具，即 KNX 也通过 MyKNX 提供 KNX 交互测试工具 (EITT)。
第 4 步：注册、测试和认证
描述:
一旦 KNX 成员充分检查了一致性（在开发过程中），就可以将应用程序提交给 KNX 进行注册。 应用程序将在注册时由 KNX 签署。 只有签名的应用程序才能导入 ETS 并提交给 KNX 认可的测试机构进行正式的 KNX 一致性认证测试。 KNX 成员在注册后可以使用 KNX 商标为设备贴上标签，例如，为了将其商业化。