Feature Model of TinyOS makerules

Transcription

1 Feature Model of TinyOS makerules Matthias Niederhausen November 2, 2007 Contents 1 Analyzing makerules Variables of global makerules MAKERULES QUELL RECURSIVE TINYOS APPS MAKERULES DEFAULT LOCAL GROUP OPTFLAGS NESC FLAGS BASEDIR DOCDIR PLATFORMS MSG SIZE XNP TINYSEC MIB PROGRAMMER EXTRA FLAGS MIB EPRB PROGRAMMER EXTRA FLAGS STK AVRISP PROGRAMMER EXTRA FLAGS AVRISP SENSORBOARD PFLAGS CFLAGS COMPONENT PROGRAMMER EXTRA FLAGS HOME PROGRAMMER PART AVRISP DEV BUILDLESS DEPS BUILD EXTRA DEPS LDFLAGS

2 2 Feature Model MAKERULES QUELL RECURSIVE TINYOS APPS MAKERULES DEFAULT LOCAL GROUP OPTFLAGS NESC FLAGS BASEDIR DOCDIR PLATFORMS MSG SIZE XNP TINYSEC MIB PROGRAMMER EXTRA FLAGS MIB EPRB PROGRAMMER EXTRA FLAGS STK AVRISP PROGRAMMER EXTRA FLAGS AVRISP SENSORBOARD PFLAGS CFLAGS COMPONENT PROGRAMMER EXTRA FLAGS HOME PROGRAMMER PART AVRISP DEV BUILDLESS DEPS BUILD EXTRA DEPS LDFLAGS OBJCOPY SET ID PROGRAMER PROGRAMMER FLAGS INP PLATFORM Dependency Analysis Extensibility Modelling multiple nodes 32

3 1 Analyzing makerules 1.1 Variables of global makerules This part is intended to give an overview of all variables found in the global makerules file MAKERULES variable giving the location (pathname) of the global make rules file QUELL RECURSIVE TINYOS APPS MAKERULES control variable to stop recursive inclusion of makes rules file DEFAULT LOCAL GROUP seems to be a value used in the construction of ids for individual motes used in definition of PFLAGs to define DEF TOS AM GROUP variable (which does what?) example value: 0x7d conjectured domain: byte associated constraints: don t think so OPTFLAGS purpose: example value: modeling: constraints: NESC FLAGS purpose: example value: modeling: constraints: default value is -0s (this is a text string representing a flag to be passed to the nesc compiler). Meaning of 0s is unclear at this point used at the conclusion of the makefile when ncc is invoked default as 0s, constraints are that it has to be defined somewhere must be defined someone (either default), or specified by programmer in the application make file default value is -Wnesc-all (this is a text string representing a flag to be passed to the nesc compiler). Meaning of nesc-all is unclear at this point used in the definition of PFLAGS (which will used when ncc is called) default as nesc-all, constraints are that it has to be defined somewhere must be defined someone (either default), or specified by programmer in the application make file

4 1.1.6 BASEDIR purpose: domain: example values: DOCDIR comment in global makerules file says used to generated more useful package names in the documentation (we conjecture that this is something similar to Javadoc) used to define DOCDIR (below) looks like its part of a part of a path name purpose: root directory for location of documentation generated by nesdoc app (we conjecture that this is something similar to Javadoc) passed as a parameter to used to define DOCDIR (below) nesdoc is called if make is invoked with a goal docs domain: directory name (absolute or relative?) example values: modeled: default value, constraint requires that the variable is defined (Note: there is some aspect of meta-configuration here. We have a variable defining a domain of values, from which one must be selected as a feature) PLATFORMS purpose: domain: default value: modeled: constraint: MSG SIZE list of tags for platforms currently support by nesc distribution platform = (Family) (in current distribution) a text string with space separate tags where each tag is a platform name mica mica2 mica2dot pc used to define the domain of values for PLATFORM variable check is performed in global makerules. PLATFORM is supplied as argument to Make group feature at the purpose: if defined, the value is used to set one of the PFLAGS (DTOSH DATA LENGTH) to a particular value indicating the length of data (for what???) domain: integer (unknown)?? no default value default value: none (we need an example!) only used to define DTOSH DATA LENGTH variable into PFLAGS modeled: constraints: as integer if set, then optional argument to PFLAGS (DTOSH DATA LENGH) must have same value as MSG SIZE

5 XNP purpose: domain: default value: modeled: constraints: boolean flag, if set then add the network programming related files boolean (unknown)?? no default value none - seems to be a boolean flag as optional feature if set, then optional arguments (value of XNP DIR, a string/shell argument and value of COMPONENT) added to PFLAGS TINYSEC purpose: domain: default value: modeled: constraints: MIB510 purpose: domain: default value: modeled: constraints: boolean flag, if set then try to get TINYSEC-KEY variable and add some TinySec specific arguments to PFLAGS true or false as string (false incl. any string or not defined) false only used for decission if TinySec specific arguments should be added to PFLAGS or not as optional feature if set, then optional arguments (TinySec libraries, DTINYSEC KEY= and DTINYSEC KEYSIZE=) added to PFLAGS in addition: if PLAT- FORM is mica2dot then an additional argument is added to PFLAGS (-I%T/platform/mica2/TinySec) boolean flag, if set then use mib510 serial port programming board at defined port and sets PROGRAMMER and PROGRAMMER FLAGS variables none (defined or undefined) none only used for setting PROGRAMMER variable to STK and setting PROGRAMMER FLAGS variable (-dprog=mib510 and -dserial=) optional feature if set, then variable PROGRAMMER is set to value STK and some optional arguments of PROGRAMMER FLAGS variable are set ( dprog must have value mib510, dserial gets value specified in make command line (MIB510), values of PROGRAMMER PART and PRO- GRAMMER EXTRA FLAGS MIB variables are added)

6 PROGRAMMER EXTRA FLAGS MIB purpose: special flags if using mib510 programmer board domain: string default value: none if MIB510 flag is set this string is added to PROGRAMMER FLAGS which is influencing build process modeled: optional feature constraints: if MIB510 flag is set, then PROGRAMMER FLAGS includes PRO- GRAMMER EXTRA FLAGS MIB EPRB purpose: domain: default value: modeled: constraints: boolean flag, if set then use eprb programming method over network with network adress given by make command and sets PROGRAMMER and PROGRAMMER FLAGS variables none (defined or undefined) none only used setting PROGRAMMER variable to STK and setting PRO- GRAMMER FLAGS variable (-dprog=stk500 and -dhost=) optional feature if set, then variable PROGRAMMER is set to value STK and some optional arguments of PROGRAMMER FLAGS variable are set ( dprog must have value stk500, dhost gets value specified in make command line (EPRB), values of PROGRAMMER PART and PROGRAM- MER EXTRA FLAGS STK variables are added) PROGRAMMER EXTRA FLAGS STK purpose: special flags if using EPRB programmer method domain: string default value: none if EPRB flag is set this string is added to PROGRAMMER FLAGS which is influencing build process modeled: optional feature constraints: if EPRB flag is set, then PROGRAMMER FLAGS includes PROGRAM- MER EXTRA FLAGS STK

7 AVRISP purpose: if set then use AVRISP serial programmer board at defined port given by make command and sets PROGRAMMER and PROGRAM- MER FLAGS variables domain: string (unknown)?? default value: modeled: constraints: none used for setting PROGRAMMER variable to STK, setting PRO- GRAMMER FLAGS variable (-dprog=stk500 and -dserial=) and setting arguments of PROGRAMMER FLAGS INP (dprog, dserial and dpart) optional feature if set, then variable PROGRAMMER is set to value STK and some optional arguments of PROGRAMMER FLAGS variable are set ( dprog must have value stk500, dserial gets the value of this AVRISP variable, values of PROGRAMMER PART and PROGRAM- MER EXTRA FLAGS STK variables are added) PROGRAMMER EXTRA FLAGS AVRISP purpose: domain: default value: modeled: constraints: special flags if using AVRISP programmer board string none if AVRISP is set this string is added to PROGRAMMER FLAGS which is influencing build process optional feature if AVRIP is set, then PROGRAMMER FLAGS includes PROGRAM- MER EXTRA FLAGS AVRISP

8 SENSORBOARD purpose: domain: default value: modeled: constraints: adding defined sensorboard to PFLAGS variable or if undefined take default sensorboard depending on PLATFORM string if not set, then value is calculated depending on PLATFORM only used for setting value of mandatory argument (board) of PFLAGS - optional feature in application makefile - influences mandatory feature in PFLAGS - if set in application makefile, then value of PFLAGS argument must be equal to SENSORBOARD value - else - PLATFORM == mica = SENSORBOARD = micasb - PLATFORM == mica2 = SENSORBOARD = micasb - PLATFORM == mica128 = SENSORBOARD = micasb - PLATFORM == rene2 = SENSORBOARD = basicsb - PLATFORM == pc = SENSORBOARD = micasb - PLATFORM == mica2dot = SENSORBOARD = basicsb PFLAGS purpose: general initial parameters for PFLAGS. Additional argument are calculated and added by makerules domain: string default value: none value is modified several times by processing makerules. final value influences build and documentation generator modeled: optional feature in application makefile constraints: none CFLAGS purpose: gives some parameters for build - no dependencies or modifications in makerules domain: string default value: none only a parameter for build and documentation generation modeled: optional feature constraints: none

9 COMPONENT purpose: domain: default value: modeled: constraints: gives the name of a application, identifies main.nc file string (unique string identifying application) identifies.nc file to open for build if XNP is set COMPONENT is added to PFLAGS mandatory feature if XNP is set, then value must be in PFLAGS PROGRAMMER EXTRA FLAGS purpose: gives some additional flags to PROGRAMMER FLAGS and PRO- GRAMMER FLAGS INP domain: string default value: none value is added to PROGRAMMER FLAGS and to PROGRAM- MER FLAGS INP modeled: optional feature constraints: if set, then PROGRAMMER FLAGS and PROGRAM- MER FLAGS INP must include the value HOME purpose: domain: default value: modeled: constraints: assumption it is users home directory string (pathname) none used to define KEYFILE for TinySec part. points to a directory, where a file called.tinyos keyfile should be stored mandatory feature if TINYSEC is defined PROGRAMMER PART purpose: domain: default value: modeled: constraints: first its initial value is used to be included in PROGRAMMER FLAGS after that it is reassigned to a platform specific value without being used in further process -??senseless?? string none its value is added to PFLAGS not modeled yet beause unclear sense

10 AVRISP DEV purpose: if AVRISP is set, then this value is value of argument dserial of PRO- GRAMMER FLAGS INP variable. assuming this specifies a port. domain: string default value: none only used to set value of dserial argument of PROGRAM- MER FLAGS INP if AVRISP is set modeled: mandatory feature if AVRISP is set constraints: if AVRISP is set, AVRISP DEV must be set BUILDLESS DEPS purpose: domain: default value: modeled: constraints: no idea string none in rules for make install platform if BUILDLESS DEPS has something in common with MAKECMDGOALS (make command line parameters) the build will not be processed (unsure) BUILD EXTRA DEPS purpose: domain: default value: modeled: constraints: LDFLAGS purpose: domain: default value: modeled: constraints: some additional parameters for build process (assuming for linker parameters) never used somewhere else - no assignements no dependencies string none only used as a parameter when performing build process optional feature

11 2 Feature Model There are different ways to start modeling the top level of the makerule file. Simplified it is one file with many variables. Started wirh one feature which is representing the whole makerule file you can add variables(features) directly under this top level or you can put a feature group between these two levels. Since we don t care about how many features are selected in a configuration of this model there is no need for a feature group. 2.1 MAKERULES ifndef MAKERULES MAKERULES=$(shell ncc -print-tosdir)/../apps/makerules This statement is a simple definition of a default value. Whenever a user doesn t care about this variable it will be declared and it will have a default value. The default value is calculated by a shell command and gives a pathname to the default global makerules file (should be the actual processed file). In this approach of the feature modeling framework there is a possibility to model default string values for a feature. In the modeling part of the feature modeling framework you can define a default value and if a user is not defining a different value of this feature in the configuration area the default value would be set. Wherever there is a ifndef block in the makerules file with no other commands in it than defining a default values for a variable, this can be modeled as a single mandatory feature with a default string value in the modeling area. It has to be mandatory to make sure that there is always a variable with this name - no matter which value.

12 Unfortunately, in this framework a user can also change the default value in the configuration area, so it it is a little bit senseless to set a default value if the user can change it again. Modeling and configuration area should be separated from each other since there are different persons/roles who are responsible for changing entries in each area. 2.2 QUELL RECURSIVE TINYOS APPS MAKERULES ifndef QUELL_RECURSIVE_TINYOS_APPS_MAKERULES QUELL_RECURSIVE_TINYOS_APPS_MAKERULES=1 include $(MAKERULES) else... rest of file This is not just a definition of a variable because there is a second line and an else block which are changing the whole build process. It is working together with the former defined MAKERULE variable and they are making the decision which makerule file should be processed by the compiler. Simplyfied to a true/false table there are four possible workflows: MAKERULES defined QUELL R... defined process else block of actual file QUELL R... undefined process user defined makerule file (stop processing actual file) MAKERULES undefined process else block of actual file process default makerule file (stop processing actual file) (usually the default value should point to the actual opened makerule file and the compiler will start over with processing the actual file, but now with defined MAKERULE and QUELL R... variables and finally he will jump into the else block.) Of course in case where the user defines another makerule file it is not possible to model this unknown process. The three other cases mostly end in the else block of the actual makerule file. The variable itself is modeled as a simple optional feature without any attributes but unfortunately there is no way to model the exact behavior of the makerules. The idea to have an optional feature (here dummy QUELL RECURSIVE ) which includes a feature group simulating the else block comes close to the original behavior. This optional feature depends on

13 QUELL RECURSIVE TINYOS APPS MAKERULES - if this variable is defined the dummy variable is set and if it is not defined the dummy block is not set and all definitions inside this block/feature-group wouldn t be considered. For getting such a behavior a constraint has to be defined as follows: if (quellrecursivetinyosappsmakerules) then (dummyquellrecursive) else true(); Note: There is a difference between name and id of a feature. In the model the name value is always used instead for defining a constraint the id value has to be used. The name starts with dummy because the makefile generator implementation usually is treating all feature groups as a variable with multiple value entries added together to a single string with spaces (explained later when used). The generator needs a possibility to decide which purpose a certain feature group has and therefor it is coded in the generator that all features starting with dummy are ignored but their sub-items are processed as usual. 2.3 DEFAULT LOCAL GROUP ifndef DEFAULT_LOCAL_GROUP DEFAULT_LOCAL_GROUP := 0x7d This makerule part is just a default value definition like in MAKERULES. It is modeled as a mandatory feature with a string attribute and a predefined default value in the modeling area. It is a sub-item of dummy QUELL RECURSIVE feature group. 2.4 OPTFLAGS ifndef OPTFLAGS OPTFLAGS := -Os This makerule part is just a default value definition like in MAKERULES. It is modeled as a mandatory feature with a string attribute and a predefined default value in the modeling area. It is a sub-item of dummy QUELL RECURSIVE feature group. 2.5 NESC FLAGS ifndef NESC_FLAGS NESC_FLAGS := -Wnesc-all

14 This makerule part is just a default value definition like in MAKERULES. It is modeled as a mandatory feature with a string attribute and a predefined default value in the modeling area. It is a sub-item of dummy QUELL RECURSIVE feature group. 2.6 BASEDIR ifeq ($(BASEDIR)_x, _x) BASEDIR := $(shell pwd sed s@\(.*\)/apps.*$$@\1@ ) This makerule part is just a default value definition like in MAKERULES. It is modeled as a mandatory feature with a string attribute and a predefined default value in the modeling area. It is a sub-item of dummy QUELL RECURSIVE feature group. 2.7 DOCDIR ifeq ($(DOCDIR)_x, _x) DOCDIR := $(BASEDIR)/doc/nesdoc This makerule part is just a default value definition like in MAKERULES. It is modeled as a mandatory feature with a string attribute and a predefined default value in the modeling area. It is a sub-item of dummy QUELL RECURSIVE feature group. Needs a former defined BASEDIR variable. 2.8 PLATFORMS ifeq ($(PLATFORMS)_x, _x) PLATFORMS = mica mica2 mica2dot pc This makerule part is just a default value definition like in MAKERULES. It is modeled as a mandatory feature with a string attribute and a predefined default value in the modeling area. It is a sub-item of dummy QUELL RECURSIVE feature group. 2.9 MSG SIZE ifdef MSG_SIZE PFLAGS := -DTOSH_DATA_LENGTH=$(MSG_SIZE) $(PFLAGS)

15 This makerule part is a constraint which adds a string to the value of PFLAGS whenever a user or a former included makefile (local makefile, application makefile) already defined a MSG SIZE variable - no matter which value it has. MSG SIZE is modeled as an optional feature without any attributes and it is a sub-item of dummy QUELL RECURSIVE feature group. In addition to the feature there is a constraint defined: if (msgsize) then (pflags1) else true(); Since it is not possible to access the value of MSG SIZE from within the feature model constraint and copy its value to PFLAGS the copy process is postponed to runtime of make XNP ifdef XNP PFLAGS := -I$(XNP_DIR)... $(shell $(XNP_DIR)/ident.pl.ident_install_id $(COMPONENT))... $(PFLAGS) This makerule part is also a constraint which adds two strings to the value of PFLAGS. XNP itself is modeled as an optional feature with no attributes in the modeling area and it is a sub-item of dummy QUELL RECURSIVE feature group. An additional constraint is defined which is adding the two strings to PFLAGS value: if (xnp) then (pflags2) else true(); 2.11 TINYSEC ifndef TINYSEC TINYSEC := false # default: disable tinysec This first part of TINYSEC is just a default value definition. Even if this variable is supposed to be a boolen flag it is modeled as a feature with a string attribute. Since there are no further steps handling the false case of this variable and since there is no attribute for boolean values the predefined default value is true and it is modeled as an optional feature and sub-item of dummy QUELL RECURSIVE feature group. If this value is not set by user ( false value) it will be ignored by the generator anyway and if it is set its value would be true and a constraint is taking care of this case.

16 ifeq ($(TINYSEC),true) TINYSEC_KEY := $(shell mote-key -kf $(KEYFILE) -kn $(KEYNAME)) ifeq ($(TINYSEC_KEY),) $(error tinysec key has not been properly set. It is needed for \ tinysec. Check to make sure that the script exists) PFLAGS := $(PFLAGS)... -I%T/lib/TinySec... -I%T/platform/%p/TinySec... -DTINYSEC_KEY="$(TINYSEC_KEY)"... -DTINYSEC_KEYSIZE=8 ifeq ($(PLATFORM),mica2dot) PFLAGS := $(PFLAGS) -I%T/platform/mica2/TinySec There is a constraint which is modifying PFLAGS and activating TINYSEC KEY feature in case TINYSEC is set: if (tinysec) then (pflags10 and tinyseckey) else true(); Since the first version of the generator/model didn t include make command paramenters it was not possible to model the second ifeq block. But with the second version which includes make command parameters dependencies on PLATFORMS variable can now be modeled. Now there is a second constraint which adds the behaviour of the second ifeq block: if (pfmica2dot and tinysec) then (pflags5) else true(); 2.12 MIB510 ifneq ($(MIB510_),) MIB510 := $(MIB5100) This variable depends on make command parameters. It will be extracted from the command line and saved in MIB510 variable. For modeling command line parameters there is another top-level feature group called dummy MAKECMDS. MIB510 is modeled as a sub-item feature of this dummy group without any attributes.

17 ifneq (x$(mib510),x) PROGRAMMER := STK PROGRAMMER_FLAGS=-dprog=mib dserial=$(mib510)... $(PROGRAMMER_PART)... $(PROGRAMMER_EXTRA_FLAGS_MIB) There is a constraint for modifying values of PROGRAMMER and PROGRAM- MER FLAGS. Since it is not possible to define values from within a constraint, PRO- GRAMMER and PROGRAMMER FLAGS have to be modeled as feature groups and their possible values are separate sub-item features of this group with predefined values. A constraint can modify values of PROGRAMMER and PROGRAMMER FLAGS by selecting or deselecting the sub-items. MIB510, EPRB and AVRISP are defining values of the same variables PRO- GRAMMER and PROGRAMMER FLAGS. Because of that it is assumable that these three variables are excluding each other. The only possiblility to exclude two of these features is by modeling PROGRAMMER FLAGS as a feature group with three sub-items (for values depending on MIB510, EPRB and AVRISP) and to set the maximum of selected features to 1. if (mib510) then (stk and prflags1) else true(); 2.13 PROGRAMMER EXTRA FLAGS MIB no definition or constraint code in makerule file There is no part in global makerules where this variable is defined, but however its value is used. So it is modeled as an optional feature with no attributes in the modeling area. It is a sub-item of dummy WITH MAKECMDS feature group which is separating funtionality of the second version of the generator EPRB ifneq ($(EPRB_),) EPRB := $(EPRB0) This variable depends on make command parameters. It will be extracted from the command line and saved in EPRB variable. For modeling command line parameters there is another top-level feature group called dummy MAKECMDS. EPRB is modeled as a sub-item feature of this dummy group without any attributes.

18 ifneq (x$(eprb),x) PROGRAMMER := STK PROGRAMMER_FLAGS=-dprog=stk dhost=$(eprb)... $(PROGRAMMER_PART)... $(PROGRAMMER_EXTRA_FLAGS_STK) There is a constraint for modifying values of PROGRAMMER and PROGRAM- MER FLAGS. Since it is not possible to define values from within a constraint, PRO- GRAMMER and PROGRAMMER FLAGS have to be modeled as feature groups and their possible values are separate sub-item features of this group with predefined values. A constraint can modify values of PROGRAMMER and PROGRAMMER FLAGS by selecting or deselecting the sub-items. MIB510, EPRB and AVRISP are all defining values of the same variables PRO- GRAMMER and PROGRAMMER FLAGS. Because of that it is assumable that these three variables are excluding each other. The only possiblility to exclude two of these features is by modeling PROGRAMMER FLAGS as a feature group with three sub-items (for values depending on MIB510, EPRB and AVRISP) and to set the maximum of selected features to 1. if (eprb) then (stk and prflags2) else true(); 2.15 PROGRAMMER EXTRA FLAGS STK no definition or constraint code in makerule file There is no part in global makerules where this variable is defined, but however its value is used. So it is modeled as an optional feature with no attributes in the modeling area. It is a sub-item of dummy WITH MAKECMDS feature group which is separating funtionality of the second version of the generator AVRISP ifdef AVRISP PROGRAMMER := STK PROGRAMMER_FLAGS=-dprog=stk dserial=$(avrisp)... $(PROGRAMMER_PART)... $(PROGRAMMER_EXTRA_FLAGS_AVRISP)

19 In contradiction to MIB510 and EPRB the value of AVRISP is not extracted from the command line parameters. It has to be defined in another included makefile (local or application makefile). Because of this it is modeled as an optional sub-item feature of dummy QUELL RECURSIVE group and has no attributes. There is a constraint for modifying values of PROGRAMMER and PROGRAM- MER FLAGS. Since it is not possible to define values from within a constraint, PRO- GRAMMER and PROGRAMMER FLAGS have to be modeled as feature groups and their possible values are separate sub-item features of this group with predefined values. A constraint can modify values of PROGRAMMER and PROGRAMMER FLAGS by selecting or deselecting the sub-items. MIB510, EPRB and AVRISP are all defining values of the same variables PRO- GRAMMER and PROGRAMMER FLAGS. Because of that it is assumable that these three variables are excluding each other. The only possiblility to exclude two of these features is by modeling PROGRAMMER FLAGS as a feature group with three sub-items (for values depending on MIB510, EPRB and AVRISP) and to set the maximum of selected features to 1. if (avrisp) then (stk and prflags3) else true(); 2.17 PROGRAMMER EXTRA FLAGS AVRISP no definition or constraint code in makerule file There is no part in global makerules where this variable is defined, but however its value is used. So it is modeled as an optional feature with no attributes in the modeling area. It is a sub-item of dummy WITH MAKECMDS feature group which is separating funtinality of the second version of the generator SENSORBOARD ifeq ($(SENSORBOARD),) ifeq ($(PLATFORM),mica) SENSORBOARD = micasb ifeq ($(PLATFORM),mica2) SENSORBOARD = micasb ifeq ($(PLATFORM),mica128) SENSORBOARD = micasb ifeq ($(PLATFORM),rene2) SENSORBOARD = basicsb

20 ifeq ($(PLATFORM),pc) SENSORBOARD = micasb ifeq ($(PLATFORM),mica2dot) SENSORBOARD = basicsb This part of makerules sets default values for the SENSORBOARD variable depending on the value of PLATFORM (not PLATFORMS). SENSORBOARD is modeled as an optional sub-item feature of dummy QUELL RECURSIVE group and to be able to define its values it has a feature group with separate optional features for each possible value ( micasb and basicsb ). There are two contraints for defining SENSORBOARDs value depending on which value PLATFORM has: if (pfmica or pfmica2 or pfmica128 or pfpc) then (micasb) else true(); if (pfrene2 or mica2dot) then (basicsb) else true(); 2.19 PFLAGS The value of PFLAGS is modified several times while processing makerules. Its value is a string consisting of multiple strings separated by space characters. Some of those strings are always included in PFLAGS, some of them are optional and some are included by some constraints. There is no initial definition of PFLAGS - all strings are added to the former value of PFLAGS. Values always added: -Wall -Wshadow -DDEF TOS AM GROUP=$(DEFAULT LOCAL GROUP) $(NESC FLAGS) -target=$(platform) -board=$(sensorboard) -fnesc-cfile=$(builddir)/app.c $(PFLAGS) Values depending on constraints: Depends on MSG SIZE: -DTOSH DATA LENGTH=$(MSG SIZE) Depends on XNP: -I$(XNP DIR)

21 $(shell $(XNP DIR)/ident.pl.ident install id $(COMPONENT)) Depends on value of TINYSEC ( true ): -I%T/lib/TinySec -I%T/platform/%p/TinySec -DTINYSEC KEY= $(TINYSEC KEY) -DTINYSEC KEYSIZE=8 Depends on values of TINYSEC ( true ) and PLATFORM ( mica2dot ): -I%T/platform/mica2/TinySec Depends on value of PLATFORM ( pc ): -pthread -fnesc-nido-tosnodes=1000 Depends on value of PLATFORM (other than pc ): -finline-limit= if (msgsize) then (pflags1) else true(); if (xnp) then (pflags2) else true(); if (pfmica2dot and tinysec) then (pflags5) else true(); if (tinysec) then (pflags10 and tinyseckey) else true(); if (pfpc) then (pflags7 and (not pflags9)) else true(); if (pfmica or pfmica2 or pfmica128 or pfrene2 or pfmica2dot or pfall) then (pflags9 and (not pflags7)) else true(); 2.20 CFLAGS no definition or constraint code in makerule file This variable is only be used as an additional parameter for other variables or compile commands. It is modeled as an optional sub-item feature of dummy QUELL RECURSIVE with a string attribute COMPONENT no definition or constraint code in makerule file This variable is only be used as an additional parameter for other variables or compile commands. It is modeled as an optional sub-item feature of dummy QUELL RECURSIVE with a string attribute. Because it has a string attribute but there is no default value in the model the user has to define a value

22 otherwise the model is not complete an the generator wouldn t run PROGRAMMER EXTRA FLAGS no definition or constraint code in makerule file This variable is only be used as an additional parameter for other variables or compile commands. It is modeled as an optional sub-item feature of dummy WITH MAKECMDS with a string attribute HOME no definition or constraint code in makerule file KEYFILE := $(HOME)/.tinyos_keyfile This variable is only be used once for defining value of KEYFILE (part of TINYSEC) to get a pathname where to find.tinyos keyfile. Comment: Assuming this variable points to users home directory - it should be set as a system environment variable 2.24 PROGRAMMER PART ifeq ($(PLATFORM), mica) PROGRAMMER_PART=-dpart=ATmega103 --wr_fuse_e=fd ifeq ($(PLATFORM), mica128) PROGRAMMER_PART=-dpart=ATmega128 --wr_fuse_e=ff ifeq ($(PLATFORM), mica2) PROGRAMMER_PART=-dpart=ATmega128 --wr_fuse_e=ff This variable is a little bit strange - first it is used without any former definition and afterwards it is set by the upper constaints but never used again??? This is not modeled yet.

23 2.25 AVRISP DEV no definition or constraint code in makerule file This variable is only be used as an additional parameter for defining PROGRAM- MER FLAGS INP variable. It is always a part of PROGRAMMER FLAGS INP s string value but never defined - so it has to be modeled as a mandatory feature of PROGRAMMER FLAGS INP s feature group BUILDLESS DEPS ifneq ($(filter $(BUILDLESS_DEPS),$(MAKECMDGOALS)), ) else all: for platform in $(PLATFORMS); do \ $(MAKE) $$platform $(DOCS) exit 1; \ done $(PLATFORMS): build This variable is never defined in makerules and it is used only once for checking if MAKECMDGOALS has the same value BUILD EXTRA DEPS $(MAIN_EXE): $(BUILDDIR) $(BUILD_EXTRA_DEPS) FORCE... This variable is never defined in makerules and it is used only once as a parameter for executing the build process LDFLAGS $(NCC)... $(LDFLAGS) This variable is never defined in makerules and it is used only once as a parameter for executing the ncc compiler.

24 2.29 OBJCOPY OBJCOPY = avr-objcopy This variable is defined in makerules and it is used only once as a parameter for compiler execution. Since there are no dependencies there is no need to model this variable - it is coded in the generator SET ID SET_ID = set-mote-id This variable is defined in makerules and it is used only once as a parameter for compiler execution. Since there are no dependencies there is no need to model this variable - it is coded in the generator PROGRAMER PROGRAMER = uisp This variable is defined in makerules and it is used only once as a parameter for compiler execution. Since there are no dependencies there is no need to model this variable - it is coded in the generator. NOTE: Do not mix it up with PROGRAMMER variable 2.32 PROGRAMMER FLAGS INP This variable is defined in makerules and it is used only once as a parameter for compiler execution. It s value depends on the values of PLATFORM and AVRISP. If AVRISP is defined and PLATFORM is mica : PROGRAMMER FLAGS INP= -dprog=stk500 -dserial=$(avrisp DEV) -dpart=atmega103 If AVRISP is defined and PLATFORM is mica128, mica2dot : PROGRAMMER FLAGS INP= -dprog=stk500 -dserial=$(avrisp DEV) or mica2 or

25 -dpart=atmega128 If AVRISP is NOT defined and PLATFORM is mica, mica128, mica2 or mica2dot : PROGRAMMER FLAGS INP= -dprog=dapa $(PROGRAMMER EXTRA FLAGS) If PLATFORM is anything else: PROGRAMMER FLAGS INP is not defined. NOT MODELED YET PLATFORM This variable is not defined in makerules - it is a parameter extracted from the command line when attempt to run the compiler. There are many dependencies on this variable. The extraction is made by using value of PLATFORMS variable as a pattern for filtering out its value from the command line. Possible values for this variable are: mica, mica2, mica128, rene2, pc, mica2dot and all Altough this variable is treated as a string with whitespace separators it seems that it has to have one and only one value because all the dependencies in makerules are comparing its value if it matches (and not includes) one string.

26 3 Dependency Analysis This part is intended to give an overview how to identify the important features in order to develop a software product line. The former version of the feature model consists of 33 different choice points (i.e. variable that needs to be set). Some of them are only related to the make language to be able to compile it and others are related to product specific properties. In this section we analyze all choice points and try to simplify the former feature model by excluding product irrelevant properties. We start this analysis by looking at one of the most impontant features in makerules definition and see where it gets its information from. Each of these inputs need to be classified whether there values are user defined or computed by the system (e.g. environment variables or pathnames). In our case we start with the PFLAGS variable. By extracting each occurence of an assignment to PFLAGS we get the following dependency list where PFLAGS final value comes from: MSG SIZE XNP XNP DIR COMPONENT DEFAULT LOCAL GROUP PLATFORM BUILDDIR NESC FLAGS TINYSEC TINYSEC KEY Since PFLAGSs assignment statements are always of the kind PFLAGS := something $PFLAGS there is no initial value of PFLAGS. Hence we have either to add a former PFLAGS item to the dependency list or we have to highlight it in some way in the dependency diagram to see this item may has a user defined value. The following picture shows PFLAGS and all its dependencies. Highlighted items are initialy defined by user - non-highlighted items are computed (e.g. by a shell command) or their value depends on other items without beeing initialized.

27 PFLAGS itself is not affecting any other item, once it has its final value it is a parameter of the compiler command at the end. Most items in this list are exclusively for computing PFLAGS but one of them (PLATFORM) affects a list of further items: BOOTLOADER SENSORBOARD MAIN TARGET OPTFLAGS PROGRAMMER PART PROGRAMMER FLAGS INP BOOTLOADER is computed by the system and represents a pathname to a file. Its value depends on XNP DIR which gives the directory and PLATFORM which decides if the file for mica2 or mica2dot should be used. If the value of PLATFORM is set to

28 something else BOOTLOADER will not be defined. SENSORBOARD can have a user defined initial value, but if not a default value depending on the current value of PLATFORM will be assigned. MAIN TARGET is computed by the system and depends if the value of PLATFORM is set to pc or not. OPTFLAGS can have a user defined initial value, but if not a default value will be assigned. However depending on the current value of PLATFORM if it is set to pc OPTFLAGS former value will be overwritten. Furthermore OPTFLAGS depends on two more items DBG and DBG OPT, both user defined exclusively. If DBG is set it will overwrite OPTFLAGS again and if DBG OPT is set it will add a parameter string no matter which part set OPTFLAGS value. The purpose of PROGRAMMER PART is still unclear. There are several assignments to PROGRAMMER FLAGS where PROGRAMMER PART is involved to compute the value to be assigned. Since there is no former assignment to PROGRAMMER PART it must have a user definied initial value. Confusing is that after all computations where it is involved the value of PROGRAMMER PART is overwritten depending which PLAT- FORM is choosen, but after this assignment it is never used for anything. PROGRAMMER FLAGS INP is computed by the system with several dependencies. First of all it depends on the choice of the value of PLATFOM. There are four section for different platfoms the definition of PROGRAMMER FLAGS INP: mica mica128 mica2 mica2dot Each of those has one more condition depending on the choosen programmer board. If programmer board AVRISP is choosen the value of PROGRAMMER FLAGS INP is set and it will include a parameter with the string representation of AVRISP DEV. Otherwise if any other programmer board is choosen its value is set and it will include PROGRAMMER EXTRA FLAGS. Unfortunately there is no variable holding the choosen programmer board. There are four different programmer boards mentioned in makerules. If nothing is specified makerule will assume a parallel programmer board called DAPA. The three other choices are MIB510, EPRB and AVRISP, but each of them has an own boolean flag whether this board should be used or not. Unfortunately it is up to the developer to make sure only one programmer board is set. Furthermore each one of them has a user defined variable holding specific information to be added to the value of PRO- GRAMMER FLAGS.

29 This issue can be solved by introducing two new items: PROGRAMMER BOARD This item intends to hold information which programmer board should be used. It replaces the former three variables MIB510, EPRB and AVRISP. PROGRAMMER EXTRA FLAGS BOARD This item intends to hold additional information for one specific programmer board. These information need to be added to PROGRAMMER FLAGS if PRO- GRAMMER BOARD is set to any non-default value. Since there can only be one programmer board at a time there is no need to have three different variables. The following picture shows the refactored dependency diagram: The above part covers all dependencies of PFLAGS, but there is another important variable which is not covered yet and which is passed through the makerule file to the compiler. There is no assignment or condition using this variable which is called

30 CFLAGS. CFLAGS is used to hold information like radio frequency and transmission power. These values are defined in another makefile which is imported to makerule. In this file CFLAGS depends on four different properties: DCC2420 DEF CHANNEL DRADIO XMIT POWER DCC1K DEFAULT FREQ DCC2420 TXPOWER To each one of those parameters there are a lot of possible values in this file. All of them are commented out except one which is defining a part of CFLAGS. Conclusion: The following picture shows the complete dependency diagram of makerule parameters: All grey highlighted items need to be or can be defined by user. This small subset of makerule parameters gives enough information to generate a makefile but is way easier to understand. All white colored items are calculated by the system at runtime. They do not need to be defined by a user and should be hidden. The red colored item is still unclear. Therefore is has to be treated like a grey colored item.

31 3.1 Extensibility

32 4 Modelling multiple nodes This section is going to analyse and describe how we can model a whole application. The focus of the former sections was how we can model one particular node and its inner constraints, but a whole application consists of multiple nodes. Hence, we need a way to model multiple nodes and their outer constraints. Outer constraints define whether you can or you have to have multiple nodes of the same kind or which kinds of nodes do you need for a certain application. Pursuer-Evader application: The pursuer evader application is an Intruder detection and tracking application. It consists of 2 sensor grids(different group ids) which detect an intruder and pass this sensing event to a command and control station via their corresponding base stations located on a stargate.the sensing motes and the base station form a multihop tree rooted at the base station.the base station/stargate is connected by tcp/ip to the command center. The purpose of this application is to show the pursuer can change its wireless local group to communicate with different networks. Each network (i.e. sensor grid) has its unique default local group and each wireless device has to have the same default local group in order to be able to communicate with this sensor grid. Hence, the pursuer needs to change its local group while moving through different sensor grids and following the invader.

33 To demonstrate the applications purpose it needs to consists of three different kinds of nodes: Stargate Basestation Pursuer To show the change of the pursuers local group we need to have at least 2 different sensor grids with different default local group. Each sensor grid consists of exactly one stargate and one or more basestations with the same local group. Hence, we have additional constraints for this application: Sensor Grid Number of instances 2 Fixed default local group Default local group is unique for each grid Stargate Number of instances = 1 Basestation Number of instances 1 Pursuer Number of instances = 1