专利效果示例

一、考虑如下智能家居场景，用户家中有以下智能设备：

温湿度传感器、人体传感器、烟雾传感器、智能灯、智能窗户、智能报警器、智能风扇。

---

二、为了实现智能家居自动化，设置如下5条TAP规则：

1）IF 烟雾传感器检测到烟雾，THEN 智能报警器报警；
2）IF 烟雾传感器检测到烟雾，THEN 打开智能窗户15min后关闭；
3）IF 烟雾传感器检测到烟雾，THEN 打开智能风扇15min后关闭；
4）IF 室内环境潮湿，THEN 打开智能风扇10min后关闭；
5）IF 用户回家，THEN 打开智能风扇10min后关闭；
包含了有关和无关两类

---

三、考虑以下相关安全属性：

1）下雨时窗户应该处于关闭状态；
2）有烟雾时窗户应该处于打开状态；
3）有烟雾时风扇运行不应该被打断。

---

在提取设备与规则的原始信息后，以每个安全属性为单位，进行建模设备与规则的筛选。对于安全属性“下雨时窗户应该处于关闭状态”，原属性中窗户和下雨，根据建模信息筛选规则，筛选设备 智能窗户，烟雾传感器 和 TAP规则2 ，进行规则交互模型构建
在构建规则交互模型后，使用安全属性的LTL形式“G((weather.rain=raining)->F(window.switch=close))”进行规则交互漏洞的检测，产生反例，违背安全属性“”，冲突状态前的反例信息如下：

根据安全属性，初始语义为rain和window，TAP规则相关的加入smoke，构成谓词集合，设置对应的flag，flag->enum类型，同时加旧！=新，flag一开始确定后就固定住，然后安全属性规定了action必须为close
1.第一轮规则语义抽象中安全属性出现的实体属性对应的规则语义。抽象模型，2.将规则中出现的属性和3.当前系统中的实体对应的状态条件进行变异组合作为新的规则语义抽象谓词；4.通过N-Gram
首先尝试rain谓词，step变量设置为1，第一次是init后面是next(step)，加入每个非自然属性下，action设置为符号值，在某种情况下要不要执行这个action（多action基础），

---

四、抽象过程和修复空间生成、优化过程

4.1 第一版存在以下问题：

本抽象规则能代表所有规则，但无法保证规则的全局性

((flag1)->(weather.rain = raining)) & ((flag2)->(weather.rain = not_raining)) & ((flag3)->(smoke = detected)) & ((flag4)->(smoke = clear)) & ((flag5)->(alarm.alarmCap.alarm = both)) & ((flag6)->(alarm.alarmCap.alarm = off)) & ((flag7)->(alarm.alarmCap.alarm = siren)) & ((flag8)->(alarm.alarmCap.alarm = strobe)):{open, close};

一个反例就排除信息不合理，需要遍历所有反例才能排除这类谓词情况 ;
没加trigger，导致反例信息一场

    init(window.switch):=close;
    next(window.switch):=
      case
        step = 1: close;
        step = 2: close;
        -- 没更改原规则
        smoke = detected: open;
        runinwindow.timer=1&window.switch=open: close;
        TRUE:window.switch;
      esac union
      case
        step = 1: close;
        step = 2: close;
        -- 修复规则谓词的迭代方式不合理； 加入了无关的alarm
        ((flag1)->(weather.rain = raining)) & ((flag2)->(weather.rain = not_raining)) & ((flag3)->(smoke = detected)) & ((flag4)->(smoke = clear)) & ((flag5)->(alarm.alarmCap.alarm = both)) & ((flag6)->(alarm.alarmCap.alarm = off)) & ((flag7)->(alarm.alarmCap.alarm = siren)) & ((flag8)->(alarm.alarmCap.alarm = strobe)):{open, close};
        TRUE:window.switch;
      esac;

---

4.2 第二版 解决了一版的问题

做到了之前做不到的新增规则，相当于做到了改变trigger和action

    init(window.switch):=close;
    next(window.switch):=
      case
        -- 调整原规则
        smokeState != smoke & smoke = detected & ((flag1)->(weather.rain = raining)) & ((flag2)->(weather.rain = not_raining)): open;
        -- 原规则的互补规则
        --(flag3) & smokeState != smoke & smoke = detected & ((flag4)->(weather.rain = raining)) & ((flag5)->(weather.rain = not_raining)): close;
        -- 新增规则
        --((flag1|flag2) & (flag3)->(weather.rainState != weather.rain)) & ((flag1)->(weather.rain = raining)) & ((flag2)->(weather.rain = not_raining)) & ((flag4|flag5) & (flag6)->(smokeState != smoke)) & ((flag4)->(smoke = detected)) & ((flag5)->(smoke = clear)): {open,close};
        runinwindow.timer=1&window.switch=open: close;
        TRUE:window.switch;
      esac;

固定flag，保证规则全局性
加入trigger类型的flag

  INVAR
    toint(flag3) + toint(flag6) = 1
    
  ASSIGN
    next(flag1):=flag1;
    next(flag2):=flag2;
    next(flag3):=
       case
           -- 防止全员无效或者一变化就执行规则
           (next(flag1)|next(flag2))=FALSE: FALSE;
           TRUE: flag3;
       esac;
       	
    next(flag4):=flag4;
    next(flag5):=flag5;
    next(flag6):=
       case
           (next(flag4)|next(flag5))=FALSE: FALSE;
           TRUE: flag6;
       esac;	

((flag1|flag2) & (flag3)->(weather.rainState != weather.rain)) & ((flag1)->(weather.rain = raining)) & ((flag2)->(weather.rain = not_raining)) & ((flag4|flag5) & (flag6)->(smokeState != smoke)) & ((flag4)->(smoke = detected)) & ((flag5)->(smoke = clear)): {open,close};

---

4.3 第三版 解决了二版action设置为符号变量导致的错误

处理过程

1.先抽象当前的TAP规则。
2.如果抽象后仍存在反例，则抽象新TAP规则。每次新增一条。

    init(window.switch):=close;
    next(window.switch):=
      case
        -- 调整原规则
        smokeState != smoke & smoke = detected & (weather.rain = not_raining): open;
        -- 新增规则
        --((flag1|flag2) & (flag3)->(weather.rainState != weather.rain)) & ((flag1)->(weather.rain = raining)) & ((flag2)->(weather.rain = not_raining)) & ((flag4|flag5) & (flag6)->(smokeState != smoke)) & ((flag4)->(smoke = detected)) & ((flag5)->(smoke = clear)): close;
        runinwindow.timer=1&window.switch=open: close;
        TRUE:window.switch;
      esac;

有代表性的4种反例类型

1.类似原情况的close版本。做过尝试 改安全属性不行，偏离本意 G(->)不同于G(->F)不同于G(与)，应该等价于G!()，但G!()的反属性很奇怪，action breaking才存在G(->F)(延时)
2.自然属性
3.冲突状态存在的两种情况：
3.1 冲突状态不存在
3.2 冲突状态不应该以状态同时出现作为标准，而是出现之后有没有处理，任务：找没有close匹配的raining

如果为上述返利类型

则说明当前抽象不正确
INVAR
!(flag1 = TRUE & flag2 = FALSE) & !(flag1 = FALSE & flag2 = FALSE)

---

4.4 实验结果

check_ltlspec -p “G((weather.rain=raining)->F(window.switch=close))” 为TRUE

    next(window.switch):=
      case
        --smokeState != smoke & smoke = detected: open;
        smokeState != smoke & smoke = detected & (weather.rain = not_raining): open;
        (weather.rainState != weather.rain) & (weather.rain = raining) & (smoke = detected): close;
        (weather.rainState != weather.rain) & (weather.rain = raining) & (smoke = clear): close;
        runinwindow.timer=1 & window.switch=open: close;
        TRUE:window.switch;
      esac;

---

TO-DO

1.完成专利
2.分析目前方法存在的不足
3.扩展到其它场景，比如AutoTap无法解决的场景