[aadl]: On data implementations in AADL models

[Denis Buzdalov]

Dear all,

During AADLv3 discussions, Peter said about doubts on usability of
different data implementations. Here there is an example when I
sufficiently used different data implementations. I do not like this
examples in several points (for example, the fact, that at higher level
of containment we have the count of such implementations to be a
multiple of all lower-level implementations count).

This example raised when I became to need very precise model of AFDX
frame in AADL because it is being transmitted to a cosimulated OS and
thus being binary transformed.

The main attention is to ipv4_addr, ip_header and mac_addr components.

=================================================================

data afdx_frame end afdx_frame;
data implementation afdx_frame.multicast
subcomponents
	mac_header: data mac_header.impl;
	ip_header: data ip_header.multicast;
	udp_header: data udp_header.impl;
	payload: data;
end afdx_frame.multicast;

-- MAC header -- begin --
data mac_header end mac_header;
data implementation mac_header.impl
subcomponents
	mac_dst_addr: data mac_addr.dst;
	mac_src_addr: data mac_addr.src;
	connection_type: data base_types::unsigned_16;
end mac_header.impl;

data mac_addr
properties
	source_data_size => 6 bytes;
end mac_addr;

data implementation mac_addr.dst
subcomponents
	mac_const_dst: data base_types::unsigned_32;
	vl_id: data base_types::unsigned_16;
end mac_addr.dst;

data implementation mac_addr.src
subcomponents
	mac_const_src0: data base_types::unsigned_8;
	mac_const_src1: data base_types::unsigned_8;
	mac_const_src2: data base_types::unsigned_8;
	network_id: data base_types::unsigned_8;
	equipment_id: data base_types::unsigned_8;
	interface_id: data base_types::unsigned_8;
end mac_addr.src;
-- MAC header --  end  --

-- IP header -- begin --
data ip_header end ip_header;

data implementation ip_header.multicast
subcomponents
	version_and_ihl: data base_types::unsigned_8;
	type_of_service: data base_types::unsigned_8;
	total_length: data base_types::unsigned_16;
	fragment_id: data base_types::unsigned_16;
	flag_and_fragment_offset: data base_types::unsigned_16;
	ttl: data base_types::unsigned_8;
	protocol: data base_types::unsigned_8;
	header_checksum: data base_types::unsigned_16;
	src_addr: data ipv4_addr.unicast;
	dst_addr: data ipv4_addr.multicast;
end ip_header.multicast;

data implementation ip_header.unicast
subcomponents
	version_and_ihl: data base_types::unsigned_8;
	type_of_service: data base_types::unsigned_8;
	total_length: data base_types::unsigned_16;
	fragment_id: data base_types::unsigned_16;
	flag_and_fragment_offset: data base_types::unsigned_16;
	ttl: data base_types::unsigned_8;
	protocol: data base_types::unsigned_8;
	header_checksum: data base_types::unsigned_16;
	src_addr: data ipv4_addr.unicast;
	dst_addr: data ipv4_addr.unicast;
end ip_header.unicast;

data ipv4_addr
properties
	source_data_size => 4 bytes;
end ipv4_addr;

--data implementation ipv4_addr.num
--extends base_types::unsigned_32.impl end ipv4_addr.num;

data implementation ipv4_addr.unicast
subcomponents
	ip_const: data base_types::unsigned_8;
	netword_id: data base_types::unsigned_8;
	equipment_id: data base_types::unsigned_8;
	partition_id: data base_types::unsigned_8;
end ipv4_addr.unicast;

data implementation ipv4_addr.multicast
subcomponents
	ip_const: data base_types::unsigned_16;
	vl_id: data base_types::unsigned_16;
end ipv4_addr.multicast;
-- IP header --  end  --

-- UDP header -- begin --
data udp_header end udp_header;
data implementation udp_header.impl
subcomponents
	afdx_src_port: data base_types::unsigned_16;
	afdx_dst_port: data base_types::unsigned_16;
	udp_length: data base_types::unsigned_16;
	udp_checksum: data base_types::unsigned_16;
end udp_header.impl;
-- UDP header --  end  --

=================================================================

By the way, unfortunately, I couldn't avoid correct duplication of
fields in ip_header implementations because if I would write something
like this:

-----------------------------------------------------------------
data implementation ip_header.fieldy
subcomponents
	version_and_ihl: data base_types::unsigned_8;
	type_of_service: data base_types::unsigned_8;
	total_length: data base_types::unsigned_16;
	fragment_id: data base_types::unsigned_16;
	flag_and_fragment_offset: data base_types::unsigned_16;
	ttl: data base_types::unsigned_8;
	protocol: data base_types::unsigned_8;
	header_checksum: data base_types::unsigned_16;
	src_addr: data ipv4_addr.unicast;
	dst_addr: data;
end ip_header.fieldy;

data implementation ip_header.multicast extends ip_header.fieldy
subcomponents
	dst_addr: refined to data ipv4_addr.multicast;
end ip_header.multicast;

data implementation ip_header.unicast extends ip_header.fieldy
subcomponents
	dst_addr: refined to data ipv4_addr.unicast;
end ip_header.multicast;
-----------------------------------------------------------------

... then, as I was writing in the whitepaper for the winter '16 meeting,
standard (neither core, nor data modelling annex) does not say anything
about place of dst_addr field in the binary representation -- whether
it is the last field or, maybe, somewhere in the middle of whatever?

--
Denis Buzdalov
Software Engineering Department, ISPRAS