毕业设计实验——汽车操作系统权限管理模型的优化技术研究

毕设工作组成:1.威胁场景 2.源码分析 3.复现论文(实验),这篇博客关注第三部分。

实验设计

实验目的

在linux系统上复现《Context-Aware Access Control in Novel Automotive HMI Systems》,并尽可能提出改进。

实验背景&实验动机

随着汽车软件功能多样性的增加,在越来越多的汽车应用程序之间共享可用的屏幕区域变得越来越重要。目前已经提出了许多行业规范(ISO26262 等),来保障功能图像显示的安全性
(此处安全性的定义:保证显示安全关键的应用程序;防止在车辆运动时显示预期之外的、分散驾驶注意力的内容。)

然而,用户希望能够自己定制人机界面(HMI),例如,缩小速度表的大小以使用更多的显示区域进行导航,或者在HMI主题之间进行选择。为了在众多安全关键(safety-critical)和非安全关键(non-safety-critical)的应用程序之间安全地共享显示屏,需要提供访问控制的服务。即,需要在保证符合行业标准的情况下增加显示区域的灵活性。

访问控制基本概念

本文中,访问控制系统使用上下文信息来动态地确定哪些应用程序)可以访问哪个显示区域。上下文信息可以从车辆传感器(例如,当前速度)或者是应用特定的状态(例如,选择哪个菜单项)中获取。

主体:应用程序,记作S = {s1, …, sn}
客体:像素点集合(定义一个单独的像素点为atomic object),记作Λ = {λ1, …, λn}
受约束权限(constrained-permission):主体具备对客体的受约束权限,指上下文信息满足某条件时,主体可以访问客体。
可以表示为(主体,客体,上下文->上下文状态(active/inacitve)),见下文Fig. 5。
在这里插入图片描述

上下文

在这里插入图片描述
数据源(Data Sources)
car sensor data:汽车的驾驶状态或环境信息。例如车速、与前面车的距离等。
comunication events:通过通信设备输入的信息。如电话、短信等。
UI events:由用户输入所触发的事件。如导航、音乐等。
Context Providers: 处理和解释来自数据源的数据,输出上下文的状态(active/inactive)。
Presentation: 对应的像素区域的显示内容。检测到碰撞的警告、刹车失灵警告、来电、导航信息等。

上下文状态: (C1,state),C=S X N,也即上下文信息C1由一个应用程序和一个上下文ID组成。上下文状态又由上下文信息和status(active or inactive) 组成。所以,一个上下文状态可表示为(S0,N0,state),意义为在某时刻,应用程序S0的上下文N0的状态为active / inactive。
在这里插入图片描述
当前上下文信息ctx1满足(c1,active) 和(c2.inactive),此时Ssp具备访问O1的权限。

同一系统中的两个受约束条件应当具备不冲突性,即这保证了一个像素不会被多个应用程序同时访问。不冲突性需要满足:(1)像素区域O1和O2无交集 (2)当像素区域O1和O2有交集时,C1和C2不能同时被满足(存在一个c,c属于C1、C2,但是在C1、C2中c的status值不同)。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值