Priyadarshini
email: priyadarshini.-@lcis.grenoble-inp.fr

Simon Greiner
email: simon.greiner@de.bosch.com

Maike Massierer
email: maike.massierer@de.bosch.com

Oum-El-Kheir Aktouf
email: oum-el-kheir.aktouf@lcis.grenoble-inp.fr

A Method for Identifying Inconsistencies between Functional Safety and Cybersecurity of Autonomous Vehicles

Keywords: functional safety, cybersecurity, autonomous driving, autonomous vehicles, interdependencies, interferences, inconsistencies, system FMEA, SysML activity diagram, SysML internal block diagram

With the shift towards assisted and autonomous driving, more functional safety and security features are being integrated to make these systems dependable, safe, and secure. Additional safety and security features lead to increasing interdependencies and inconsistencies between them. In this paper, we propose a method to detect inconsistencies between safety and security by assessing the potential impact of security features on safety-critical components of a system. For the assessment, we analyze artifacts from the Failure Mode and Effects Analysis and SysML models of the overall system. We apply our method to an example, i.e. we evaluate whether the security feature secure onboard communication (AUTOSAR SecOC) could potentially cause a failure of the safety-critical communication. Our method identifies potential interactions between safety-critical components and security features by reusing available functional safety and security artifacts generated as a part of their independent analyses.

I. INTRODUCTION

Automotive systems are currently changing at a fast pace. On the one hand, the complexity of safety-relevant vehicle functionalities is growing quickly due to rapid progress in automation of driving functions. On the other hand, an increase in connectivity of vehicles leads to larger attack surfaces, which in turn requires more and more protection mechanisms against cyberattacks.

Safety engineering is an established discipline in automotive engineering and regulated mainly in the automotive functional safety standard ISO 26262 [START_REF]International Organization for Standardization[END_REF]. In comparison, regulation for cybersecurity is relatively new, and the upcoming road vehicle cybersecurity standard ISO/SAE FDIS 21434 [START_REF]ISO/SAE FDIS 21434: Road vehicles -Cybersecurity engineering[END_REF] will most likely be the leading regulation. Both norms pose rigorous engineering requirements on processes and measures to protect the safety and security of vehicles. However, their interaction is limited, and a closely coupled co-engineering of safety and security engineering is not trivial, if sensible at all. As a result, safety and security engineering are practically performed in parallel without much interaction by experts in the respective fields during different phases of the development.

The distribution of safety and security engineering activities between different people and their division into separate tasks bears the risk that safety and security will interfere with each other. For example, a security analysis may require protection against attacks on communication (for instance in the form of firewalls or message authentication that might discard messages for security reasons), while safety relies on the assumption that every message received by a system is processed. The requirements resulting from both disciplines therefore can have unintended interdependencies. If these unintended interdependencies are detected too late during system development, e.g. during final testing, this can require changes of the overall system architecture. This is very expensive and can lead to delays in the start of production of a vehicle.

In this paper, we propose a method to identify conflicts between safety and security solutions resulting from the potential impact of security features on the safety-critical components of a system. We focus only on safety-critical communication interfaces, such as the Ethernet communication interface, as they are typical entry points for an attacker. This method is based on the artifacts created during safety and security engineering and on semi-formal models of the system architecture. Furthermore, the method provides the potential impact of identified inconsistencies on the system level. As a prototypical analysis, we have manually applied this method to a real subsystem that is illustrated with an example of a security feature called secure onboard communication (SecOC) [START_REF] Autosar | Specification of Secure Onboard Communication[END_REF], an automotive standard protocol for authentication of communication (Com) in vehicle bus systems.

This paper is structured as follows. In the following section, we shortly introduce safety and security related artifacts of respective analyses on which our method builds. In Section III, we introduce our method. In Section IV, we discuss related work, and finally, we conclude.

II. FUNCTIONAL SAFETY AND CYBERSECURITY ANALYSIS

We assume that functional safety and security analyses have been performed on the system of interest. We reuse the artifacts of these analyses in our method. In particular, we briefly introduce the system level failure modes and effects analysis (FMEA) and system modeling language (SysML) models of security features on which our method is based.

A. System FMEA

A system FMEA [START_REF] Vda-Qmc | VDA Volume 4 -Quality Assurance before series production Part 2[END_REF], [START_REF] Vda-Qmc | VDA Volume 4 -Quality Assurance in the Process Landscape[END_REF]Chapter 4] is a structured approach for systematic analysis of potential failures of a system, socalled failure modes. It has five steps: structure analysis, function analysis, failure analysis, actions analysis, and optimization. We limit our description to the first three steps, since only these are required for our method.

1) Structure analysis: A structure analysis diagram shows a hierarchical order of a system and its system elements, including their interfaces. 2) Function analysis: Function analysis provides an overview of the functions and sub-functions implemented by each system element. Additionally, it highlights the cause-andeffect relationships between functions and sub-functions.

3) Failure analysis: In this step, potential failure modes are deduced from each function of every system element, stating what can go wrong for each function and sub-function. In Fig. 2, the failure analysis for the ETH Com IF shows that this system element implements the function of providing external communication (green text). For this function, four different failure modes have been identified (red text).

Failure structures show how failure modes of different system elements are related to each other. For example, the failure net depicted in Fig. 3 shows how a failure mode of the ETH Com IF leads to a failure mode in the Control unit, which itself causes a failure mode in the DA System. In the notion of failure analysis, the failure structure shows causes and effects for each failure mode.

B. SysML models of a security feature

We assume that SysML [START_REF]SysML Open Source Project -What is SysML? Who created it?[END_REF] models exist for the security features implemented by the system. In particular, we assume a structural model of each security feature and its environment in the form of an internal block diagram and a behavioral model of the security feature as an activity diagram. Initially, the secure onboard communication block performs four actions (orange rounded rectangles), and then -depending on the evaluation of a condition (green diamond) -it performs another action before the activity terminates.

III. A METHOD FOR IMPACT ANALYSIS OF SECURITY ON

SAFETY

In this section, we propose a method to assess the potential impact of the functional behavior of a security feature on the safety-critical components of a system. Our method consists of three steps. In the first step, for each interface mentioned in the FMEA structure analysis we identify related security features. In the second step, we analyze whether the functional behavior of the security feature can lead to a failure mode related to the interface. In the third step, we identify the impact of the failure mode caused by the security feature.

To illustrate our method, we use the security feature secure onboard communication (SecOC) and a safety-critical Ethernet (ETH) communication interface as a running example. SecOC is defined by the AUTomotive Open System ARchitecture (AUTOSAR) [START_REF]AUTOSAR[END_REF] and verifies the freshness and authenticity of messages communicated over an Ethernet bus. Communication interfaces provided by a system to its environment are typically an entry point for attackers. Therefore, many security features protecting against such attacks have an influence on the communication via these interfaces. At the same time, many safety-relevant malfunctions of automotive embedded systems have an effect on the communication via an interface (e.g. data corruption, omission, or wrong timing of messages). For this reason, we use communication interfaces as the initial connection between the safety analysis and the model of the security features.

In the first step of our method, we collect all interfaces with failure modes assigned to them in the FMEA structure analysis. For each of these interfaces we identify the corresponding port in the SysML model of the system. For the port, we collect all blocks modeling security features that have a data flow to or from this port. As a result, we know the port over which the security feature could intervene with the safety-relevant communication interface.

In our example, we first choose the ETH Com IF highlighted in Fig. 1. The corresponding port in the SysML model is the port ETH Com IF of the Control unit highlighted in Fig. 4. By analyzing the data flow in the SysML model, we can identify that the Secure Onboard Communication block can intervene with communication on the ETH Com IF port via 5 and Port 6.

B. Step 2: detection of potential inconsistencies

In the second step, we analyze whether the control flow of the security feature has an influence on the communication over the port(s) identified in the previous step. We also identify the failure modes of the interface selected in step 1 that this Fig. 5. Example of an activity diagram influence corresponds to. We use activity diagrams to perform the control flow analysis and the FMEA failure analysis to identify the corresponding failure mode(s). The potential inconsistency is identified by analyzing whether the control flow of the security feature could cause one or more failure modes on the identified port in step 1. We collect these failure modes to assess their impact in step 3.

In our example, the activity diagram of the secure onboard communication block shows that the received messages are discarded depending on the result of a freshness and authenticity check (green diamond in Fig. 5). Therefore, there is the potential that a safety-critical message is lost, which is equivalent to the failure mode no reception from ETH com IF (data loss) in Fig. 2.

C. Step 3: impact analysis of detected inconsistencies

In the third step, we identify the potential impact of the interference detected in the previous step. There, we identified the failure mode that could be caused by the security feature. We now use the failure net of the identified failure mode to analyze its failure effects on different elements of the system.

In our example, the failure net in Fig. 3 shows that the identified failure mode no reception can lead to the effects faulty communication on the level of the Control unit and faulty communication on the level of the DA System. After identifying the potential conflict and its resulting impact, relevant stakeholders should be invited for reviewing and resolving the conflict.

IV. RELATED WORK

In this section, we briefly review existing methods focussing on the identification, characterization, and resolution of safety and security interdependencies. Four types of interdependencies between safety and security are identified in [START_REF] Piètre-Cambacédès | Modeling safety and security interdependencies with BDMP (Boolean Logic Driven Markov Processes)[END_REF], namely conditional, reinforcement, antagonism, and independence. Safety and security could each act as a condition for the other, complement each other, conflict with each other when considered separately for the same system, or be independent of each other. In this paper, we focus on conflicts resulting from inconsistent safety and security features specified in the corresponding safety and security requirements that are allocated to the same system.

Different approaches have been explored in the literature to master these interdependencies, such as formal methods and model-based methods. Piètre-Cambacédès and Bouissou [START_REF] Piètre-Cambacédès | Modeling safety and security interdependencies with BDMP (Boolean Logic Driven Markov Processes)[END_REF] propose an approach based on a Boolean logic driven Markov processes dynamic formalism to graphically model risk scenarios and characterize safety and security interdependencies. Martin et al. [START_REF] Martin | Combined automotive safety and security pattern engineering approach[END_REF] focus on a consideration of security aspects within a safety engineering lifecycle and propose a systematic pattern-based approach that interlinks safety and security patterns. Gu, Lu, and Li [START_REF] Gu | Extracting Interdependent Requirements and Resolving Conflicted Requirements of Safety and Security for Industrial Control Systems[END_REF] analyze and classify the relationship between safety and security requirements in industrial control systems as interdependent, conflicted, and unrelated. In [START_REF] Sun | Addressing Safety and Security Contradictions in Cyber-Physical Systems[END_REF] and [START_REF] Gu | Extracting Interdependent Requirements and Resolving Conflicted Requirements of Safety and Security for Industrial Control Systems[END_REF], the authors propose a formal framework to analyze conflicts in security and safety requirements.

Although some of these works focus on the identification of safety and security conflicts in the requirements phase, we argue that the requirements themselves may not be conflicting, but still the resulting safety and security measures could be. Cui et al. [START_REF] Cui | A review on safety failures, security attacks, and available countermeasures for autonomous vehicles[END_REF] point out the need for future research into the consistency between safety and security countermeasures when they are developed independent of each other. To harmonize the potential conflicts, bidirectional analysis is essential to assess the impact of security features on system safety and of safety mechanisms on system security. Our contribution is the proposed method to assess the potential impact of security features on critical safety components of a system by reusing the existing artifacts of functional safety and cybersecurity engineering.

V. CONCLUSION AND FUTURE WORK

In this paper, we have presented a method to assess the potential impact of security features on the communication interfaces that are safety-critical and may serve as an entry point for attackers at the same time. This method does not combine functional safety and cybersecurity analysis as a joint method but rather checks for potential interactions between them by reusing available functional safety and cybersecurity artifacts generated as a part of their independent analyses. Since this method is performed at the system level, safety and security inconsistencies can be identified in early development phases to optimize resources and to resolve these inconsistencies through either trade-off or co-design and co-development.

In future work, we will develop a model-based automation tool to automate our proposed method. The tool will allow us to assess the impact of security features not only on defined safety-critical communication interfaces, but also on other system elements in the FMEA system structure, such as external memory. We will further investigate additional information and parameters that can support our analysis, whereby the identified security features with a potential impact on safety-critical system elements will also be traceable to the corresponding system security requirements.

Fig. 1 .

 1 Fig. 1. FMEA structure analysis -an example of a system structure For example, Fig. 1 shows a simplified example of a structure analysis diagram for a Vehicle. It is composed of a driver assistance system called DA System, which comprises different system elements, such as a Control unit and a Process unit. These system elements can have different interfaces, such as the Com interfaces. These can be further classified as the Ethernet (ETH), FlexRay, and UART communication interfaces (IF), shown as ETH Com IF, FlexRay Com IF, and UART Com IF, respectively.2) Function analysis: Function analysis provides an overview of the functions and sub-functions implemented by each system element. Additionally, it highlights the cause-andeffect relationships between functions and sub-functions.3) Failure analysis: In this step, potential failure modes are deduced from each function of every system element, stating what can go wrong for each function and sub-function.

Fig. 2 .

 2 Fig. 2. FMEA function and failure analysis

1 )

 1 Internal block diagram (IBD): A block in SysML represents a system, a hardware, or a software component. An internal block diagram is a SysML structure diagram that shows the encapsulated structural contents (parts, properties, connectors, ports, interfaces) for a given block. For example, Fig. 4 shows that the Control unit consists of the ETH Hardware Software Interface (HSI), the Secure Onboard Communication, and the Hardware Security Module components. Further, it shows that the Control unit is connected to the external Ethernet interface communication module called External ETH IF via the ETH Com IF ports. 2) Activity diagram: A SysML activity diagram defines the behavior of the block it belongs to. It defines the functional behavior and control flow in the form of actions and conditions for a block. For example, Fig. 5 shows an activity diagram for the block secure onboard communication.

Fig. 3 .

 3 Fig. 3. Example of an FMEA failure net

ACKNOWLEDGMENT

This work is supported by the French National Research Agency in the framework of the "Investissements d'avenir" program (ANR-15-IDEX-02).


Marisa N Lytle
email: m.n.lytle@psu.edu

Jérôme Prado

James R Booth
email: james.booth@vanderbilt.edu

A neuroimaging dataset of deductive reasoning in school-aged children

Keywords:

a b s t r a c t

Here we describe "Brain development of deductive reasoning" a pediatric neuroimaging dataset freely available on OpenNeuro.org. This dataset includes neuroimaging and standardized assessment data from 56 participants aged 8.47-15 years. Functional Magnetic Resonance Imaging (fMRI) data were collected while participants completed both setinclusion and linear-order deductive reasoning tasks. A subset of participants ( n = 45) returned two years later for follow-up standardized assessment testing allowing for future research to investigate individual change in cognitive and academic skill. Previous research on this dataset has not examined the relation of skill and demographic measures to the neural basis of reasoning. Moreover, these studies have not examined the relation of the neural basis of reasoning to that of arithmetic or differences between children and adults in the neural basis of reasoning. Therefore, there are many opportunities to extend the research in the published reports on this data.

Specifications Table

Subject Developmental Cognitive Neuroscience Specific subject area

Neuroimaging of Deductive Reasoning in School-aged Children Type of data Tables Images How data were acquired 3T Siemens Trio-Tim scanner, 16-channel head coil. E-prime software was used to display tasks and collect behavioral data. Data format Raw Parameters for data collection All participants were right-handed, native English speakers, having normal or corrected to normal vision and no history of psychological or neurological disorders, prematurity of less than 36 weeks, head injury causing overnight hospitalization, hearing loss, or contraindications for MRI.

Description of data collection

Participants ( n = 56) completed standardized measures of cognitive and academic ability, a practice MRI scan in a mock scanner, a structural MRI scan, and functional MRI scans while performing deductive reasoning tasks. In addition, a subset of children ( n = 45) returned two years later and completed follow-up standardized testing. Data

Value of the Data

• Extensive skill and demographic measures allow for examination of how these variables are related to the neural basis of reasoning. • Longitudinal assessment scores allow for prediction of individual change from behavioral or neuroimaging data. • Matched participants with an external dataset allows for the comparison of the neural basis of reasoning and arithmetic. • Parallel adult participants in an external dataset allows for examination of developmental differences. • Compliance with Brain Imaging Data Structure (BIDS) specifications supports ease of future use.

Data Description

All raw data are freely available in the public neuroimaging dataset entitled "Brain Development of Deductive Reasoning" hosted on OpenNeuro.org [START_REF] Lytle | Brain Development of Deductive Reasoning[END_REF] . The data are organized in accordance with the Brain Imaging Data Structure Specifications which allow for easy reuse of the data as well as utilization of tools that work with this standard [START_REF] Gorgolewski | The brain imaging data structure, a format for organizing and describing outputs of neuroimaging experiments[END_REF] . The dataset includes raw and standardized scores from a battery of neuropsychological standardized assessments and questionnaires used to quantify cognitive and academic skill, structural Magnetic Resonance Imaging (MRI) images, functional MRI images collected while participants completed two deductive reasoning tasks, and behavioral data from those tasks. Table 1 in this article describes the number of subjects having completed each of the fMRI tasks by sex and Fig. 1 provides an illustration of the task design and timing.

This dataset has been used in part in one publication [START_REF] Mathieu | Distributed neural representations of logical arguments in school-age children[END_REF] . In addition, this dataset is accompanied by a larger dataset entitled "Brain Correlates of Math Development" which investigates arithmetic development in the same participants [START_REF] Suárez-Pellicioni | Brain Correlates of Math Development[END_REF] . The arithmetic dataset is described in Suárez-Pellicioni et al., is freely available on OpenNeuro.org and includes longitudinal fMRI tasks of rhyming, numerosity, multiplication, and subtraction processing [START_REF] Suárez-Pellicioni | A longitudinal neuroimaging dataset on arithmetic processing in 8-to 16-year old children[END_REF] . This dataset is also accompanied by an adult dataset on the same experimental tasks in the scanner, but with a reduced number of individual difference variables outside of the scanner [ 5 , 6 ]. The presently described dataset contains a new and unique contribution of deductive reasoning fMRI tasks that overlaps with the arithmetic dataset in standardized assessment scores and structural imaging data. This dataset will allow for the examination of many additional research questions that have not yet been examined. First, participants completed an extensive standardized testing battery. This will allow others to examine the relation of skill measures to the neural basis of reasoning. Second, demographic data will allow researchers to compare variables such as socio-economic status to the neural basis of reasoning. Third, the overlap in subjects with the arithmetic dataset will allow for the examination of the connection between reasoning and arithmetic. Fourth, comparable adult data has been uploaded onto OpenNeuro, so studies can examine developmental differences.

Experimental Design, Materials and Methods

Participants

This dataset includes neuroimaging and standardized assessment data from 56 participants aged 8.47-15 years (mean age = 11.20, SD = 1.64, 32 female) at the first time point, session T1.

A subset of participants, aged 10.91-16.47 years ( n = 45, mean age = 13.47, SD = 1.59, 25 females) returned two years later for session T2 to complete follow up standardized testing. Participants completed additional neuroimaging tasks at both session T1 and T2 which are available in a previously published dataset [START_REF] Prado | Fractioning the neural substrates of transitive reasoning: task-dependent contributions of spatial and verbal representations[END_REF] . All participants were recruited from the greater Chicago area through flyers, advertisements, and community events. Participants were screened and included only if they were right handed, native English speakers, had no uncorrected visual or hearing loss, and had no parent report of neurological disease, epilepsy, prematurity of less than 36 weeks, birth complications requiring admission to the neonatal intensive care, head injury requiring emergency medical evaluation, taking medication affecting the central nervous system, or contraindications for MRI.

Standardized assessments and questionnaires

Standardized assessments of cognitive and academic skill were administered during the first visit of session T1. These assessments included the Test of Mathematical Abilities 2nd Edition (TOMA-2) [START_REF] Brown | Test of Mathematical Abilities[END_REF] , the Automated Working Memory Assessment (AWMA-S) [START_REF] Alloway | Automated Working Memory Assessment Manual[END_REF] , the Comprehensive Math Abilities Test (CMAT) [START_REF] Hresko | CMAT: Comprehensive Mathematical Abilities Test[END_REF] , the Comprehensive Test of Phonological Processing (CTOPP) [START_REF] Bruno | Comprehensive test of phonological processing (CTOPP)[END_REF] , the KeyMath-3 [START_REF] Connolly | KeyMath-3 Diagnostic Assessment: Manual Forms A and B[END_REF] , the Test of Word Reading Efficiency (TOWRE) [START_REF] Torgesen | TOWRE: Test of Word Reading Efficiency[END_REF] , the Woodcock-Johnson Third Edition (WJ-III) [START_REF] Woodcock | [END_REF] , and the Weschler Abbreviated Scales of Intelligence (WASI) [START_REF] Wechsler | Wechsler Abbreviated Scale of Intelligence[END_REF] . Guardians also completed the Attention Deficit and Hyperactivity Disorder (ADHD) Rating Scale-IV [START_REF] Dupaul | ADHD Rating Scale-IV: Checklists, Norms, and Clinical Interpretation[END_REF] and a questionnaire of developmental history. The developmental history questionnaire asked parents/guardians about their child's difficulties and diagnosed disorders, school environment, learning preferences, parental/family demographics, and parental/family medical history. A complete list of the questions on the developmental history questionnaire is located in the accompanying data dictionary in the phenotype directory of the dataset. A subset of participants returned two years later for session T2 and were administered all but the CTOPP and the developmental history questionnaire.

Practice imaging

Prior to the day of scanning all participants completed a practice MRI session in a mock scanner to become familiar with the scanning environment and the tasks. Participants were trained to remain still in the scanner using an infrared tracking device that would signal when participants moved their head more than 2 mm. Participants were introduced to the tasks outside the mock scanner via a presentation and then practiced the tasks inside the mock scanner. All practice tasks contained half as many trials as the in-scanner tasks, organized into one run, and did not contain any of the stimuli used in the in-scanner tasks.

Functional imaging tasks

Participants completed two deductive reasoning tasks while in the scanner called Syllogistic Reasoning and Transitive Reasoning. Tasks only differed in the type of reasoning problem that was solved. Each experimental trial contained one problem consisting of three premises and a conclusion. Half of the conclusions required the integration of all three premises and half required the integration of only two premises. In addition, some conclusions included a negation to make conclusions less predictable. This amounted to 36 problems organized into four groups; 18 true and affirmative problems (true_affirm), 6 false and affirmative problems (false_affirm), 6 true with negation problems (true_negate), and 6 false with negation problems (false_negate). Each category was further split into those requiring 2 premises to make the judgment and those requiring 3 premises to make the judgment for a total of eight conditions, premises required is denoted by a number preceding the validity in the condition name (i.e. 2_true_affirm). Premises and the conclusion were presented sequentially in 2 s intervals, with the next premise appearing below the last (i.e. first premise at 0 s, second at 2 s, third at 4 s, and conclusion at 6 s). Premises were presented in grey text while the conclusion was presented in black text to make it clear that a judgment had to be made. Each problem was also simultaneously presented auditorily through headphones. Once presented with the conclusion, participants were given 6 s to press one of two buttons to judge the validity of the conclusion given the premises. The trial continued as soon as participants provided a response or, after 6 s had passed, a red asterisk appeared below the conclusion for 2 s to indicate that no response had been made. At the end of each trial, a jittered red fixation cross was presented on the screen for 2.8-3.6 s. Fig. 1 illustrates an experimental trial in the Syllogistic Reasoning task. Each task also included 18 null trials to serve as a baseline correction. In these trials, a blue cross appeared on the screen for 2.8-3.6 s followed by a red cross for 2.8-3.6 s and participants were asked to press the button under their first finger when they saw a blue cross. Participants could respond as soon as they saw the blue cross and until it turned red. The trial would continue to the red cross as soon as the participant responded. Each task contained 54 trials total which were divided into two runs to allow for breaks and reduce participant fatigue. Each run ended with the presentation of a black fixation cross for 10 s.

Imaging and behavioral data are stored within each subject folder and titled sub-< sub_ID > _task-< task_name > _ bold.nii and sub-< sub_ID > _task-< task_name > _ events.tsv respectively, where sub-ID is the number assigned to the subject and task_name is the name of the functional task. Task names were shortened to syllogisms and transitive. Behavioral tab separated values files include trial onset, duration, type, accuracy, response time, premise text, conclusion text, and auditory stimulus file name.

Syllogistic reasoning

In the syllogistic reasoning task, participants were presented with set-inclusion problems. In this task, the premises described a series of relationships among three classes. In each problem, the first class was a monosyllabic pseudoword, and the second and third classes were one of sixteen adjectives: tall, short, big, small, old, young, fast, slow, brown, red, black, blue, green, white, or pink. The first premise stated that the first class was included in the second class and the second premise stated that the second class was included in the third class. The third premise of each problem characterized an imaginary character as belonging to one of the classes. An example of a valid and affirmative problem necessitating the integration of two premises was: (1) All blons are pink, (2) All pink things are young, (3) Ken is a blon, (C) Ken is pink.

Transitive reasoning

In the transitive reasoning task, participants were presented with linear order problems. In this task, the premises described a linear ordering of 4 imaginary characters. Each character had a single syllable name and one of eight comparative adjectives was used throughout: slower, faster, shorter, taller, younger, older, smaller, or bigger. An example of a valid and affirmative problem necessitating the integration of two premises was: [START_REF] Lytle | Brain Development of Deductive Reasoning[END_REF] Wes is older than Pam, (2) Pam is older than Tim, (3) Tim is older than Wes, (C) Wes is older than Tim.

Additional tasks

Some participants completed additional fMRI tasks as part of a larger dataset [START_REF] Prado | Fractioning the neural substrates of transitive reasoning: task-dependent contributions of spatial and verbal representations[END_REF] . These data are publicly available on OpenNeuro.org in the data repository, "Brain Correlates of Math Development" and are described in Suárez-Pellicioni et al. [START_REF] Lytle | Brain Correlates of Deductive Reasoning in Adults[END_REF] . Participant labels are consistent across these datasets to allow for combined analyses.

MRI acquisition protocol

Magnetic Resonance Images were acquired at Northwestern University Center for Advanced Magnetic Resonance Imaging (CAMRI) using a 16-channel head coil in a 3T Siemens Trio-Tim scanner running Siemens Syngo software version MR B17. Participants were provided a righthanded button box to respond to the tasks during the scans. All tasks were presented on a screen behind the scanner in a counterbalanced order, and were viewed through a mirror attached to the head coil. During MPRAGE data acquisition, participants viewed a movie.

T1-weighted MPRAGE images were acquired with the following parameters: TR = 2300 ms, TE = 3.36 ms, matrix size = 256 × 256, bandwith = 240 Hz/Px, slice thickness = 1 mm, number of slices = 160, voxel size = 1 mm isotropic, flip angle = 9 °.

Blood oxygen level dependent signal (BOLD) was acquired using a T2-weighted susceptibility weighted single-shot echo planar imaging (EPI) with the following parameters: TR = 20 0 0 ms, TE = 20 ms, matrix size = 128 × 120, bandwidth = 1302 Hz/Px, slice thickness = 3 mm (0.48 mm gap), number of slices = 32, voxel size = 1.7 × 1.7 × 3.0 mm, flip angle = 80 °, GRAPPA acceleration factor = 2. Slices were acquired interleaved from bottom to top with even slices acquired first. Tasks were subject paced resulting in a variable amount of volumes being collected for each run.

Quality control

Neuroimaging data followed a predefined series of steps to organize the data in accordance with the Brain Imaging Data structure, assess data quality, and remove identifying information. First, all data were converted from Dicom to nifti format with MRI Convert version 2.0 and necessary imaging parameters were extracted from the dicom header. These parameters are consistent across all subjects and are stored in a data dictionary file at the root level of the dataset for each task. All nifti images were then reoriented to the anterior commissure and facial features were removed from structural images. Facial features were removed by first running the FreeSurfer tool mri_deface on the images [START_REF] Bischoff-Grethe | A technique for the deidentification of structural brain MR images[END_REF] . If, upon visual inspection, the face was not removed, images were then defaced manually by aligning the raw image to a template image using mri_robust_register and then using the inversion of the resulting transformation matrix to transform a facemask to the raw image space which was then multiplied by the raw image [START_REF] Reuter | Highly accurate inverse consistent registration: a robust approach[END_REF] . All structural images were reviewed to ensure no facial features remained.

On occasion, participants completed tasks on separate dates or completed structural scans in a different session. Shifted acquisition dates are included in the participants data table at the root level of the dataset. Dates were shifted from -365 to 0 days within a subject and were then shifted back 200 years to make the date shifting transparent.

In addition, due to high movement associated with collecting data from pediatric populations all functional images were reviewed for movement using the ArtRepair toolbox [START_REF] Mazaika | Artifact repair of fMRI data from high motion clinical subjects[END_REF] . Any runs containing greater than 25% of all volumes with movement greater than 1.5 mm of volume to volume translation were removed from the dataset.

  Mathieu, J.R. Booth, J. Prado, Distributed Neural Representations of Logical Arguments in School-Age Children, Hum. Brain. Mapp. 36 (2015), 996-1009. https://doi.org/10.1002/hbm.22681 .

	source location	Northwestern University Center for Advanced Magnetic Resonance
		Imaging (CAMRI), Chicago, IL
	Data accessibility	Repository name: OpenNeuro Data identification number:
		10.18112/openneuro.ds002886.v1.0.0 Direct URL to data:
		https://openneuro.org/datasets/ds002886/versions/1.0.0
	Related research	R.
	articles

Table 1

 1 Number of participants completing each task. Number of participants by sex having completed each experimental task.

				Number of participants
			Female	Male	Total
	Syllogistic	Run 1	30	21	51
	reasoning	Run 2	29	21	50
	Transitive	Run 1	28	17	45
	reasoning	Run 2	29	21	50

Acknowledgments

This collection and organization of this dataset was supported by the National Institute of Child Health and Human Development [grant number R03-HD069781] awarded to James R. Booth. We thank Rachna Mutreja, John Binzak, and Ece Demir-Lira for their help with data collection and disseminating parts of this research as well as the children and families for their participation.

Ethics Statement

Informed consent was obtained from all participants and their guardians and all protocols were approved by the Institutional Review Board at Northwestern University. In addition, all identifiable information was removed from the dataset to protect participant privacy.

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.