AADL Core Questions Denis Buzdalov Alexey Khoroshilov Alexander Ugnenko SAE AS-2C AADL Winter Meeting 2014

Transcription

1 AADL Core Questions Denis Buzdalov Alexey Khoroshilov Alexander Ugnenko SAE AS-2C AADL Winter Meeting 2014

2 Question 1

3 Q1: The Problem Sender Receiver Data flow: Sender Receiver Implementation is not known yet Latency requirement (< 100 ms) Question: How to represent the requirement in AADL?

4 Q1: Existing Solutions There is no good solution, we have to: define connection(s) between processes define end to end flow over connection(s) define requirements (for example by property associations) for end to end flow

5 Q1: Possible Solution Allow to declare End To End Flow Specifications without connections: process A features out_feature : out feature; flows out_flow : flow source out_feature; end A; process B features in_feature : out feature; flows in_flow : flow sink in_feature; end A; system sys end sys; system implementation sys.impl subcomponents a : process A; b : process B; flows fl : end to end flow a.out_flow -> b.in_flow; end sys.impl;

6 Question 2

7 Q2: The Problem

8 Q2: The Problem

9 Q2: The Problem

10 Q2: The Problem

11 Q2: The Problem

12 Q2: The Problem

13 Q2: The Problem

14 Question 3

15 Q3: The Problem Length_Unit : type units ( mm, cm => mm * 10, m => cm * 100, km => m * 1000 ); Time_Unit : type units ( sec, min => sec * 60, hour => min * 60 ); Speed_Unit : type units ( mph, mpsec => mph * 3600, kmpsec => mpsec * 1000, kmph => mph * 1000 ); Manually describe Cartesian product of units Unreadable units abbreviations

16 Q3: Possible Solution Two new types of expressions: Derived unit types expression can be used when a value can be expressed as a multiplication and division of some other unit types. Example in a declaration of a property data_speed_prop1 : aadlinteger units Size_Units / Time_Units; Example in a declaration of a unit type Data_Speed_Units : type units Size_Units / Time_Units; data_speed_prop2 : aadlinteger units Data_Speed_Units; A set of units of such unit types can be derived automatically from existing units as a combination. Example of derived unit expressions data_speed_prop1 => 1 byte / sec; data_speed_prop2 => 8 GByte / hour;

17 Q3: Still A Problem? ISQ (international system of quantities) defines force as a multiplication of mass and length divided to a second power of time. To express this with suggested derived unit types expressions it is enough to define Force_Units in the following way: Force_Units : type units Mass_Units * Length_Units / Time_Units^2; or with some intermediate unit types (as it seems to be more adequate): Speed_Units : type units Length_Units / Time_Units Acceleration_Units : type units Speed_Units / Time_Units; Force_Units : type units Mass_Units * Acceleration_Units; But SI (international system of units) that bases on ISQ, defines 1 newton as 1 kg * 1 m / 1 sec^2.

18 Q3: Still A Problem? (2) Force_Units : type units (newton, knewton => newton * 1000); annex unit_relations (** Force_Units[newton] = Mass_Units[kg] * Length_Units[m] / Time_Units[sec]^2; **) But why relation between unit type Acceleration_Units and related Speed_Units can be expressed in AADL Core, while relation between Force_Units and Mass_Units cannot?

19 Q3: Possible Solution #2 Two new types of expressions + something else: Force_Units : type units Mass_Units * Acceleration_Units (newton, knewton => newton * 1000 );

20 Q3: Possible Solution #2 Two new types of expressions + something else: Force_Units : type units Mass_Units * Acceleration_Units (newton ==> kg * m / sec^2, knewton => newton * 1000 );

21 Q3: Namespace Problems property set PS1 is A_units : type units (a1, a2 => a1 * 10); a_prop : aadlinteger units A_units; end PS1; property set PS2 is B_units : type units (b, b1 => b * 100); C_units : type units A_units * B_units (c ==> a1*b1, a1 => c * 100); end PS2; property set PS3 is c_prop : aadlinteger units C_units * B_units; end PS3;

22 Q3: Namespace Problems package P1 public with PS1; system S1 properties PS1::a_prop => 10 a1; -- using of just a1 is ok because -- only PS1 is imported. end S1; end P1;

23 Q3: Namespace Problems package P2 public with PS1, PS2, PS3; system S2 properties -- PS1::a_prop => 10 a1; -- using of just a1 is NOT ok -- because it is ambiguous. PS1::a_prop => 10 PS1::A_units[a1]; PS2::c_prop => 10 PS1::A_units[a1]*PS1::B_units[a1]; end S2; end P2;

24 Question 4

25 Q4: The Problem AADL Specification is silent about semantics of property 'Implemented_As' How to combine a detailed model of a component with a bigger picture?

26 Q4: Case #1 CPM_Model_XYZ

27 Q4: Consistency Rules CPM is substituted by CPM_Model_XYZ i.e. subdeclarations from CPM_Model_XYZ can be referenced in CPM

28 Q4: Case #2 CPM_Model_XYZ

29 Q4: Consistency Rules CMP_Model_XYZ must has the same interfaces as CPM_Type: for each feature and flow of CPM_Type there is one with the same identifier in CMP_Model_XYZ and it follows 'refined to' rule

30 Q4: Case #3 CPM_Model_XYZ

31 Q4: Consistency Rules Namespace of CPM is a composition of namespaces of CPM_Type.impl and CPM_Model_XYZ i.e. subdeclarations from CPM_Model_XYZ can be referenced in CPM property values evaluated according to the rules in AADL-11.3 (12) as if CPM_Model_XYZ extends CPM_Type.impl

32 Q4: Consistency Rules CMP_Model_XYZ must be consistent with CPM_Type.impl: If CMP_Model_XYZ contains a classifier feature with the same identifier as in CPM_Type.impl, it have to follow 'refined to' rule

33 Q4: Implemented_As for Buses??? Provides Bus Access refinement System have to Provide Bus Accesses? Mapping? Virtual Bus does not provide Bus Access? Bindings to Virtual Bus to system?

34 Question 5

35 Q5: The Problem

36 Q5: The Problem

37 Q5: The Problem

38 Q5: The Problem

39 Q5: The Problem

40 Q5: Possible Solution Introduce a new category 'VIRTUAL MEMORY' Subcomponents of this category may be defined in PROCESSOR or VIRTUAL PROCESSOR components Components of 'VIRTUAL MEMORY' can have subcomponents only same category (possibility for defining regions of address space) Components of 'VIRTUAL MEMORY' can be bound to 'MEMORY' components If allow to define subcomponents of 'VIRTUAL MEMORY' outside PROCESSOR components then allow these subcomponents bind to processors. Binding will define relations between processor and address space

41 Question 6

42 Q6: The Problem A possibility of defining modes in component types As described in AADL-4.3(1): A component type specifies the external interface of a component that its implementations satisfy. Component types shouldn't define any internal structures of component. It is prerogative of component implementations.

43 Q6: The Problem (2) ABSTRACT comptype //define features FLOWS fl1 : flow source f1 in modes (m1); MODES m1 : initial mode; m2 : mode; END comptype; ABSTRACT systype //define features FLOWS sysfl1 : flow source f1; END systype; ABSTRACT IMPLEMENTATION systype.impl SUBCOMPONENTS subc1 : ABSTRACT comptype; // define connections FLOWS sysfl1 : flow source subc1.fl1 -> conn1 -> sysfl1; END systype.impl; // 'fl1' is active in mode 'm1', when subcomponents mode is changed to 'm2' implementation 'systype.impl' becomes invalid // by the way, semantics of 'in modes' subclause isn't described in AADL-10.1 (Flow Specifications)

44 Q6: The Problem (3) PROCESSOR x86 //define characteristics MODES realmode : initial mode; protectedmode : mode; END x86; PROCESSOR IMPLEMENTATION x86.vxwork653 SUBCOMPONENTS part_1 : VIRTUAL PROCESSOR in modes (partitions_set_1); part_2 : VIRTUAL PROCESSOR in modes (partitions_set_1); part_3 : VIRTUAL PROCESSOR in modes (partitions_set_2); part_4 : VIRTUAL PROCESSOR in modes (partitions_set_2); MODES // we can't declare modes if they defined in the type partitions_set_1 : initial mode; partitions_set_2 : mode; END x86.vxwork653; // Declaration of modes in the component types creates difficulties in reusing a third-party designed components

45 Question 7

46 Q7: The Problem (1) There is a family of processors: x86, ARM and a family of operating systems: GNU/Linux, Windows. How to describe core processing modules (CPM) based on these components in terms of AADL?

47 Q7: Existing Solutions (1) processor x86 properties -- processor specific properties end x86; processor Linux_x86 extends x86 properties -- OS specific properties end Linux_x86; processor arm properties -- processor specific properties end arm; processor Linux_arm extends arm properties -- OS specific properties (copy from 'Linux_x86') end Linux_arm; processor Windows_x86 extends x86 properties -- OS specific properties end Windows_x86; processor Windows_arm extends arm properties -- OS specific properties (copy from 'Windows_x86') end Windows_arm;

48 Q7: Existing Solutions (2) processor x86 properties -- processor specific properties end x86; processor Linux_x86 extends x86 properties -- OS specific Copy properties properties end Linux_x86; processor arm properties -- processor specific properties end arm; processor Linux_arm extends arm properties -- OS specific properties (copy from 'Linux_x86') end Linux_arm; processor Windows_x86 extends x86 Copy properties properties -- OS specific properties end Windows_x86; processor Windows_arm extends arm properties -- OS specific properties (copy from 'Windows_x86') end Windows_arm;

49 Q7: The Problem (2) The task is a bit complicated, if there will be more types of processors (x86, arm, ppc, atmega, sparc,...) and more types of OS (GNU/Linux, Windows XP, Windows 7, Solaris, NetBSD,...). => Cartesian product of a set of types of processors on a set of types of operating systems

50 Q7: The Problem (3) Next problem is modeling CPM with same CPU+OS but with different interfaces: processor Linux_x86 extends x86 -end Linux_x86; processor Linux_x86_AFDX extends Linux_x86 features if : requires bus access AFDX; processor Linux_x86_CAN extends Linux_x86 features if : requires bus access CAN; end Linux_x86_AFDX; end Linux_x86_CAN; processor Linux_x86_A429 extends Linux_x86 features if : requires bus access A429; end Linux_x86_A429;

51 Q7: The Problem (4) Next problem is modeling CPM with same CPU+OS but with different interfaces: processor Linux_x86 extends x86 -end Linux_x86; processor Linux_x86_AFDX_CAN processor Linux_x86_CAN_A429 extends Linux_x86 extends Linux_x86 features features if_1 : requires bus access AFDX; if_1 : requires bus access CAN; if_2 : requires bus access CAN; if_2 : requires bus access A429; end Linux_x86; end Linux_x86; processor Linux_x86_A429_AFDX extends Linux_x86 features if_1 : requires bus access A429; if_2 : requires bus access AFDX; end Linux_x86;

52 Q7: Possible Solution processor x86 -end x86; processor Linux -end Linux; processor Linux_x86 extends Linux, x86 -end Linux_x86; processor withcan features ifcan : R.B.A. CAN; end withcan; processor Linux_x86_1 extends Linux, x86 -end Linux_x86_1; processor arm -end arm; processor Linux_arm extends Linux, arm -end Linux_arm; processor withafdx features ifcan : R.B.A. AFDX; end withafdx; processor Linux_x86_2 extends Linux, x86 -end Linux_x86_2;

53 Q7: Benefits eliminate copy/paste of usable logic blocks (properties, features, features properties) enable reusability of component type declarations make Instance_Of operator usable

54 Q7: Issues (1) abstract A features f : feature; properties PS::Prop => 1; end A; abstract BA features f : in data port; properties PS::Prop => 2; end BA; abstract CA features f : out event port; properties PS::Prop => 3; end CA; abstract BA_CA extends BA, CA -end BA_CA; Kind of feature 'f'? Value of property 'PS::Prop'?

55 Q7: Issues (1) Possible Solution abstract A features f : feature; properties PS::Prop => 1; end A; abstract A features f : out event port; properties PS::Prop => 3; end A; abstract A features f : in data port; properties PS::Prop => 2; end A; PS::Prop = 3 (inherit from CA, last reference in 'extends') abstract BA_CA extends BA, CA -end BA_CA; Feature 'f' may/must be refined in 'BA_CA'. Prohibit inheritance if refinement isn't possible.

56 Q7: Issues (2) abstract A modes m1 : initial mode; end A; abstract C modes m3 : initial mode; end C; abstract B modes m2 : initial mode; end B; abstract ABC extends A, B, C -end ABC; Set of modes?

57 Q7: Issues (2) Possible Solution abstract A modes m1 : initial mode; end A; abstract C modes m3 : initial mode; end C; abstract B modes m2 : initial mode; end B; abstract ABC extends A, B, C -end ABC; Is modes declarations actually need in component type declaration? Modes describes internal structure of component. But component type is used for define external intefaces of component (see AADL_4.3 (1)).

58 Thank you!