我们先来看第一小段：
Conformance：合规
这里说到，系统可能是real（真实的）、planned（计划的）或imagined（想象的）。
这是从生命周期的维度来观察系统的状态，适用于所有系统。还可以从系统核心域的维度来观察系统的状态，例如，洗碗机（系统）有Washing、Rinsing和Drying等状态。
至于planned和imagined有什么区别，规范在后文也没有进一步解释。可能是一个已经有一些文案，一个还在大脑中吧？要不就是染上了类似领域驱动设计伪创新中的砌词毛病：业务用户领域需求。
关键是，不管在大脑中还是形成文案，内容不是从天上掉下来的，都需要通过建模的思维来推导。
the machine-readable files take precedence：（发生冲突时）以机器可读的文件为准。为什么这样，接下来它就给出了解释。
一个合规的SysML模型应该符合Clause 8，也就是元模型：
然后说到两个语法：
Concrete Syntax：具体语法。
就是面向建模人员的接口，包括文本的、图形的，也可以有更多，例如为残障人士提供的接口。
Abstract Syntax：抽象语法。
用元模型上面的概念来表达。
例如，Part相关的元模型是这样的：
（1）一段具体语法的SysML文本像这样：
part def Vehicle {
part engine : Engine;
attribute mass : Real;
port powerOutput : PowerPort;
}
part def Engine {
attribute power : Real;
}
（2）对应图形像这样：
这两个都是面对建模人员的更简洁的表达方式，类似于编程语言里的“语法糖”：
public string Name { get; set; }
（3）抽象语法的表达可能是这样的：
用的是元模型里的PartDefinition、PartUsage等概念来表达。
之前的UML以及XMI有（2）（3）部分，没有规定（1）的部分，后来由PlantUML等弥补，但没有统一的标准。SysML现在把这个给补上了。
关于前面的表示跟后面的模型的区别
我写过有一篇有意思的：
