TECHNICAL FIELD

The present application relates generally to the control of vehicular traffic, and relates more particularly to controlling one or more traffic lights that govern vehicular traffic at a junction of roads.

BACKGROUND

Among the many kinds of services conceivable within a ^" smart cities" paradigm, one of paramount importance is urban traffic control. In big cities, increasing traffic intensities are constantly creating huge traffic jams and the standard approach for managing traffic lights (fixed-time controllers) are not able to maintain the situation under reasonable parameters anymore. Adaptive traffic controllers, which measure current traffic conditions and try to employ dynamic policies, are available but still without a standard approach being employed in real cases.

The first applications of traffic signal control began using fixed-time control methods, with a predetermined cycle and split time plan, i.e., green light duration as a portion of the cycle time. These signal control systems assume a periodic operation, in which each light goes through its sequence of phases with calculated split parameters in a cycle that is offset from its neighbors. A fixed-time plan can be built using offline optimization tools, based on historical traffic flow data, for specific time periods. Fixed-time plan control systems are convenient for relatively stable and regular traffic flows.

Real-time traffic-responsive control uses sensing technologies to make traffic control actions under a certain control strategy according to real-time traffic data. The cycle length might be dynamically adjusted to meet the traffic demand. The Sydney Co-ordinated Adaptive Traffic System (SCATS) dynamically adjusts common cycle length of a given traffic network (or sub-network) to meet the traffic demand. The SCOOT (Split Cycle and Offset Optimization Technique) method and the ACS-Lite are examples which rely on the fixed-time offline calculation as a baseline or contingency plan. In some traffic control systems, each intersection decides which phase to apply in order to enforce safety and other constraints, rather than being oriented towards a parametric timing.

Other approaches attempt to introduce computational intelligence, in an effort to simulate the intelligence of nature to some extent. These approaches employ technologies such as artificial neural networks, fuzzy systems, and evolutionary computation algorithms.

Some approaches consider the problem only locally, restricted only to a small number of traffic lights. Some reactive methods can achieve good performance for isolated intersections, making decisions quickly based on traffic flow, like interval between vehicles or anticipated queues of vehicles, but these methods are susceptible to sub-optimal decisions. However, when dealing with the whole urban network, because of the nonlinear and stochastic events which happen in the network and their inter-dependencies, the actual state of traffic becomes hard to assess and the effects of changes in traffic control become almost impossible to forecast. The problem is therefore very complex, and even if the use of computational intelligence can help improve efficiency, in particular cases, those approaches prove difficult to scale. Hence, how to achieve scalable network-wide optimization remains a challenging problem.

In short, most solutions (i.e. fixed and dynamic reactive, computational intelligence based such as genetic algorithms and neuro-fuzzy, and others) suffer from being reactive or relying on local information only which makes it very hard to control the traffic network in a more global manner. More intelligent and global solutions are necessary to reduce average travel times and jams.

SUMMARY

Some embodiments herein provide a cognitive manager for traffic control, e.g., in an urban environment. The cognitive manager controls a set of traffic lights in a junction of roads based on information collected from sensors installed on the lanes feeding the junction. The cognitive manager seeks to optimize one or more performance indices (e.g., in the form of a drive) so as to for instance optimize the average waiting times for all the cars crossing the junction. In some embodiments, the cognitive manager at the same time provides preference to special cars (e.g., police cars or fire truck), called Smart Cars, and equipped with special devices that grant them special treatment during the phase allocation policies provided by the architecture.

Certain embodiments may provide one or more of the following technical advantage(s): (i) Reduced average travel time for vehicles in traffic; (ii) Reduced occurrence of traffic jams; (iii) Prioritization of selected vehicles (a.k.a. smart vehicles); or (iv) Improved environment sustainability (e.g. reduced emissions). Some embodiments also prove scalable, e.g., such that they are capable of first employing simple local solutions, followed by increasing scale-ups including new capabilities, in order to improve the solution, as new details and strategies become available, and are able to be incorporated in the solution.

More particularly, embodiments herein include a method performed by a junction cognitive manager (e.g., as hosted by host equipment) for controlling one or more traffic lights that govern vehicular traffic at a junction of roads. The method may include obtaining a change drive characterizing a need to change a phase of the one or more traffic lights and a maintain drive characterizing a need to maintain the phase. In some embodiments, for example, the change drive and the maintain drive are based on traffic conditions at the junction as sensed by one or more sensors. Regardless, the method may further include generating a change evaluation metric and a maintain evaluation metric as a function of the change drive and the maintain drive, respectively. In some embodiments, the change evaluation metric indicates an importance of changing the phase for satisfying the change drive and the maintain evaluation metric indicates an importance of maintaining the phase for satisfying the maintain drive. The method may also include making a decision between changing the phase and maintaining the phase, based on the change evaluation metric and the maintain evaluation metric. In some embodiments, the method may further include controlling the one or more traffic lights to change the phase or maintain the phase in accordance with the decision.

In some embodiments, the change drive includes a change activation level representing an intensity of the change drive, a change urgency threshold defining an activation level above which the change drive is in a state of urgency, and a change priority to which the change evaluation metric is assigned while the change drive is in a state of urgency. Alternatively or additionally, in some embodiments, the maintain drive includes a maintain activation level representing an intensity of the maintain drive, a maintain urgency threshold defining an activation level above which the maintain drive is in a state of urgency, and a maintain priority to which the maintain evaluation metric is assigned while the maintain drive is in a state of urgency. In some of these embodiments, generating the change evaluation metric comprises calculating the change evaluation metric as a function of the change priority if the change drive is in a state of urgency and as a function of the change activation level if the change drive is not in a state of urgency. Alternatively or additionally, generating the maintain evaluation metric comprises calculating the maintain evaluation metric as a function of the maintain priority if the maintain drive is in a state of urgency and as a function of the maintain activation level if the maintain drive is not in a state of urgency.

In some embodiments, making the decision comprises deciding to change the phase or maintain the phase depending respectively on whether the change evaluation metric or the maintain evaluation metric is larger.

In some embodiments, the traffic conditions on which the change drive and the maintain drive are based include a difference between average occupancy in all lanes of the junction.

In some embodiments, the change drive and the maintain drive are also based on whether a current phase of the one or more traffic lights complies with a constraint on a minimum time for which any phase of the one or more traffic lights must be maintained and/or a constraint on a maximum time for which any phase of the one or more traffic lights is permitted to be maintained.

In some embodiments, the method further comprises generating a reactive behavior evaluation metric as a function of a traffic situation index and generating, based on the reactive behavior evaluation metric, a reactive behavior

recommendation that recommends the phase be changed or maintained. For example, in one embodiment, the traffic situation index is a function of an average speed of vehicles in lanes of the junction. Regardless, in this case, making the decision comprises making the decision also based on the reactive behavior evaluation metric and the reactive behavior recommendation.

In some embodiments, the method further comprises generating a random behavior evaluation metric as a function of a random parameter and generating, based on the random behavior evaluation metric, a random behavior

recommendation that recommends the phase be changed or maintained. In this case, making the decision comprises making the decision also based on the random behavior evaluation metric and the random behavior recommendation.

In some embodiments, making the decision comprises making the decision also based on whether one or more exceptional conditions dictate that the phase be changed or maintained. In one embodiment, for example, the one or more exceptional conditions include an emergency vehicle needing to traverse the junction. In this case, then, the method may further comprise receiving a request for collaboration from a vehicle cognitive manager of the emergency vehicle requesting collaboration with the junction cognitive manager for traversing the junction. In some embodiments, making the decision comprises making the decision also based on a request for collaboration from a different junction cognitive manager that controls one or more different traffic lights at a different junction of roads. The request for collaboration may request the junction cognitive manager to control the phase of the one or more traffic lights at the junction in collaboration with the different junction cognitive manager’s controlling of the phase of the one or more different traffic lights at the different junction.

In some embodiments, the junction cognitive manager has a Multipurpose Enhanced Cognitive Architecture, MECA.

In some embodiments, the method further comprises collecting, by one or more sensory codelets of the junction cognitive manager, sensor data sensed by the one or more sensors and populating the sensor data in sensory memory of the junction cognitive manager.

In some embodiments, the method further comprises generating, by a changing motivational codelet of the junction cognitive manager, the change drive and generating, by a maintaining motivational codelet of the junction cognitive manager, the maintain drive.

In some embodiments, the change evaluation metric is generated by a changing behavioral codelet of the junction cognitive manager and the maintain evaluation metric is generated by a maintaining behavioral codelet of the junction cognitive manager.

In some embodiment, the method further comprises writing the decision in a Boolean memory object of the junction cognitive manager that commands a motor codelet of the junction cognitive manager to change the phase or maintain the phase. In this case, controlling is performed by the motor codelet according to the command from the Boolean memory object.

Embodiments herein also include a method performed by a coordinator cognitive manager (e.g., as hosted by host equipment). The method may include determining, based on control signaling received from a vehicle cognitive manager of a vehicle, a junction cognitive manager that controls one or more traffic lights governing traffic at a junction of roads which the vehicle is to traverse. The method may further include signaling information to the vehicle cognitive manager indicating the determined junction cognitive manager.

Embodiments further include a method performed by a vehicle cognitive manager of a vehicle in accordance with other particular embodiments. The method may include transmitting signaling to a coordinator cognitive manager requesting information indicating a junction cognitive manager that controls one or more traffic lights governing traffic at a junction of roads which the vehicle is to traverse. The method may also include receiving from the coordinator cognitive manager a response including the requested information. The method may further include transmitting to the indicated junction cognitive manager a request for collaboration requesting collaboration with the junction cognitive manager for traversing the junction.

Embodiments also include corresponding apparatus, computer programs, and carriers. For example, embodiments include host equipment configured to host a junction cognitive manager for controlling one or more traffic lights that govern vehicular traffic at a junction of roads. The junction cognitive manager is configured (e.g., via processing circuitry of the host equipment) as follows. The junction cognitive manager is configured to obtain a change drive characterizing a need to change a phase of the one or more traffic lights and a maintain drive characterizing a need to maintain the phase. In some embodiments, for example, the change drive and the maintain drive are based on traffic conditions at the junction as sensed by one or more sensors. Regardless, the junction cognitive manager is further configured to generate a change evaluation metric and a maintain evaluation metric as a function of the change drive and the maintain drive, respectively. In some embodiments, the change evaluation metric indicates an importance of changing the phase for satisfying the change drive and the maintain evaluation metric indicates an importance of maintaining the phase for satisfying the maintain drive. The junction cognitive manager in some embodiments is also configured to make a decision between changing the phase and maintaining the phase, based on the change evaluation metric and the maintain evaluation metric. In some embodiments, the junction cognitive manager is configured to control the one or more traffic lights to change the phase or maintain the phase in accordance with the decision.

Embodiments moreover include host equipment configured to host a coordinator cognitive manager. The coordinator cognitive manger is configured (e.g., via processing circuitry of the host equipment) as follows. The coordinator cognitive manager is configured to determine, based on control signaling received from a vehicle cognitive manager of a vehicle, a junction cognitive manager that controls one or more traffic lights governing traffic at a junction of roads which the vehicle is to traverse. The coordinator cognitive manager is also configured to signal information to the vehicle cognitive manager indicating the determined junction cognitive manager.

Embodiments further include host equipment configured to host a vehicle cognitive manager of a vehicle. The vehicle cognitive manager is configured (e.g., via processing circuitry of the host equipment) as follows. The vehicle cognitive manager is configured to transmit signaling to a coordinator cognitive manager requesting information indicating a junction cognitive manager that controls one or more traffic lights governing traffic at a junction of roads which the vehicle is to traverse. The vehicle cognitive manager may also be configured to receive from the coordinator cognitive manager a response including the requested information. The vehicle cognitive manager is configured in some embodiments to transmit to the indicated junction cognitive manager a request for collaboration requesting collaboration with the junction cognitive manager for traversing the junction.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of a junction cognitive manager for a junction of roads according to some embodiments.

Figure 2A is a block diagram illustrating generation of a change evaluation metric as a function of a change drive according to some embodiments.

Figure 2B is a block diagram illustrating generation of a maintain evaluation metric as a function of a maintain drive according to some embodiments.

Figure 3 is a block diagram of interaction between a junction cognitive manager, vehicle cognitive manager, and a coordinator cognitive manager according to some embodiments.

Figure 4 is a block diagram of some components of a junction cognitive manager according to some embodiments.

Figure 5 is a block diagram of various details of a junction cognitive manager according to some embodiments.

Figure 6 is a high-level diagram of a motivational-based control system according to some embodiments.

Figure 7 is a block diagram of various cognitive managers in an urban traffic context.

Figures 8A and 8B are block diagrams of a Multipurpose Enhanced

Cognitive Architecture (MECA) Cognitive Architecture according to some embodiments. Figure 9 is a block diagram of possible values of an Eval parameter depending on whether a drive is in a normal state or a state of urgency.

Figure 10 is a block diagram of a junction according to some embodiments.

Figure 1 1 is a block diagram of a signalized small network and its phases according to some embodiments.

Figure 12 is a block diagram of the architecture of a Cognitive Manager for a junction Composite Virtual Object (CVO) according to some embodiments.

Figure 13 is a block diagram of a behavioral subsystem of the cognitive manager in Figure 12 according to some embodiments.

Figure 14 is a block diagram of a motivational and perceptual subsystem of the cognitive manager in Figure 12 according to some embodiments.

Figure 15 is a block diagram of a System 2 subsystem of the cognitive manager in Figure 12 according to some embodiments.

Figure 16 is a block diagram illustrating enforcement of a rule for handling smart cars according to some embodiments.

Figure 17 is a block diagram illustrating enforcement of another rule for handling smart cars according to some embodiments.

Figure 18 is a block diagram illustrating enforcement of yet another rule for handling smart cars according to some embodiments.

Figure 19 is a block diagram illustrating enforcement of still another rule for handling smart cars according to some embodiments.

Figure 20 is a block diagram illustrating enforcement of another rule for handling smart cars according to some embodiments.

Figure 21 is a logic flow diagram of a method performed by a junction cognitive manager according to some embodiments.

Figure 22 is a logic flow diagram of a method performed by a coordinator cognitive manager according to some embodiments.

Figure 23 is a logic flow diagram of a method performed by a vehicle cognitive manager according to some embodiments.

Figure 24 is a block diagram of host equipment configured to host a junction cognitive manager according to some embodiments.

Figure 25 is a block diagram of host equipment configured to host a coordinator cognitive manager according to some embodiments.

Figure 26 is a block diagram of host equipment configured to host a vehicle cognitive manager according to some embodiments. DETAILED DESCRIPTION

Some embodiments provide a junction cognitive manager 10 as shown in Figure 1 for vehicular traffic control. The junction cognitive manager 10 controls a set of one or more traffic lights 12 that govern vehicular traffic at a junction 14 of roads 16A, 16B, i.e., by controlling a phase of the traffic light(s) 12. The junction cognitive manager 10 may do so based on information collected from sensors 18 installed on lanes feeding the junction 14. The junction cognitive manager 10 may seek to optimize one or more performance indices (e.g., in the form of a drive) so as to for instance optimize the average waiting times for all the cars crossing the junction 14. In some embodiments, the junction cognitive manager 10 at the same time provides preference to special cars (police cars, fire trucks, or other emergency vehicles), which may be called Smart Cars. Such Smart Cars may be equipped with special devices (e.g., in the form of dedicated hardware integrated into the cars, or in the form of standard smart phones with special applications) that grant them special treatment during phase allocation policies.

The junction cognitive manager 10 according to some embodiments has cognitive abilities in the sense that the junction cognitive manager 10 observes the junction 14 (e.g., via the sensors 18) and makes behavior choices. These behavior choices in some embodiments notably include motivational behavior choices, as described more fully below. The junction cognitive manager 10 in some

embodiments may also receive feedback from the junction 14 and/or learn (e.g., in order to make future behavior choices based on past and current feedback regarding previous behavior choices). Alternatively or additionally, the junction cognitive manager 10 in some embodiments may interact with other cognitive managers (e.g., a coordinator cognitive manager and/or a vehicle cognitive manager) as described below, e.g., in order to collaborate with them.

More particularly, behaviors can be in one of the following classes: random, Reactive, or goal-directed (i.e., motivational) behaviors. Any closed-loop control system, like a thermostat, performs a sort of goal-directed behavior. When a thermostat determines the control signals to a cooler system, it is not simply reacting to an input, but it is changing the environment in order for a goal (e.g. a reference temperature) to be reached. And due to the inherent feedback of a closed-loop system, the environment slowly converges to this temperature. But goal-directed systems can be much more complex than a simple thermostat. The definition of a goal might be as simple as a precise future state to be reached, or involve desired properties for a still unknown future state, where any feasible future state meeting these properties might be acceptable.

Accordingly, motivational behavior is driven by a so-called drive. A drive may characterize a need, e.g., the intensity of the need, in the form for example of one or more variables. A drive in this sense may be used as a measurement of a desirable future state which must be reached, e.g., to achieve a goal. A drive may be associated with a desirable behavior an artificial agent desires to manifest and be involved with a desirable future state for the agent. So, a drive can be seen as a measurement of the agent’s success in achieving a purpose. Also, a behavior which is performed to satisfy a drive is said to be a motivational behavior.

Considering that a drive is a kind of a measure of the intensity of a need, this drive is used to evaluate the relative importance of a specific behavior it is attached to. So, many alternative behaviors may be evaluated in parallel, according to the agent's many needs and a dynamic subsumption mechanism according to some embodiments selects the behavior related to the most urgent need. It is implicit in this view that the behavior affected by the drive might cause a reduction in the corresponding need.

In some embodiments, the junction cognitive manager 10 herein makes a decision between changing the phase of the junction’s traffic light(s) 12 and maintaining the phase, based on evaluating a drive characterizing a need to change the phase and a drive characterizing a need to maintain the phase. The junction cognitive manager 10 may for instance evaluate these alternative motivational behaviors in parallel and select the behavior related to the most important or urgent need. The junction cognitive manager 10 may make such a decision at each of multiple time instances.

Figure 1 in this regard shows that the junction cognitive manager 10 obtains a change drive 20A characterizing a need to change the phase of the junction’s traffic light(s) 12 and a maintain drive 20B characterizing a need to maintain the phase of the junction’s traffic light(s) 12. The change drive 20A and the maintain drive 20B are shown as each being based on traffic conditions 22 at the junction 14 as sensed by the sensor(s) 18.

In some embodiments, for example, the traffic conditions 22 include a difference between average occupancy in all lanes of the junction 14, e.g., where the occupancy of each lane may depend on the length of the lane, the number of cars waiting in the lane, and the size of the vehicles in the lane. In this case, if the difference between average occupancy in the junction’s lanes exceeds a threshold, the change drive 20A may indicate it is important to change the phase of the junction’s traffic light(s) 12 and the maintain drive 20B may indicate it is not important to maintain the phase. However, if the difference falls below the threshold, the change drive 20A may indicate it is not important to change the phase of the junction’s traffic light(s) 12 and the maintain drive 20B may indicate it is important to maintain the phase.

In these and other embodiments, though, the change drive 20A and the maintain drive 20B may be subject to minimum and/or maximum timing

requirements for the traffic light(s) phase. For instance, the change drive 20A and the maintain drive 20B in some embodiments may also be based on whether a current phase of the traffic light(s) 12 complies with a constraint on a minimum time for which any phase of the traffic light(s) 12 must be maintained and/or a constraint on a maximum time for which any phase of the traffic light(s) 12 is permitted to be maintained. Such constraint(s) may trump and/or be prioritized over other factor(s) on which the drives 20A, 20B depend. For example, in some embodiments, if the current phase of the traffic light(s) 12 exceeds the maximum time, the change drive 20A may unconditionally indicate it is important to change the phase of the traffic light(s) 12 and the maintain drive 20B may unconditionally indicate it is not important to maintain the phase of the traffic light(s) 12. Similarly, if the current phase of the traffic light(s) 12 falls below the minimum time, the change drive 20A may unconditionally indicate it is not important to change the phase of the traffic light(s)

12 and the maintain drive 20B may unconditionally indicate it is important to maintain the phase of the traffic light(s) 12.

As one example, then, the change drive 20A and the maintain drive 20B may be represented by respective activation levels that indicate how important the need is to change or maintain the phase, respectively. The activation level A _c for the change drive 20A may be calculated as:

where Q is the current phase time of the traffic light(s) 12, Q ^* is the maximum time the traffic light(s) 12 is permitted to be maintained in any phase, 0 _* is the minimum time the traffic light(s) 12 must be maintained in any phase, and DO is the difference between the average occupancy in all lanes of the junction 14. And the activation level A _m for the maintain drive 20B may be calculated as:

In this implementation, the activation levels for the change and maintain drives 20A, 20B have values between 0 and 1 , with a larger value indicating the need for the drive is more important.

Regardless, to evaluate these drives 20A, 20B, the junction cognitive manager 10 generates a change evaluation metric 24A as a function of the change drive 20A, and generates a maintain evaluation metric 24B as a function of the maintain drive 20B. The change evaluation metric 24A indicates the importance of changing the phase of the junction’s traffic light(s) 12 for satisfying the change drive 20A, whereas the maintain evaluation metric 24B indicates the importance of maintaining the phase of the junction’s traffic light(s) 12 for satisfying the maintain drive 20B.

In some embodiments, the change evaluation metric 24A and the maintain evaluation metric 24B are generated as a function of multiple components of the change drive 20A and the maintain drive 20B, respectively. As shown in Figure 2A, for example, the change drive 20A may be formed from multiple components that include a change activation level A _c , a change priority p, and a change urgency threshold Q. The change activation level A _c represents an intensity of the change drive 20A, e.g., so as to indicate how important the need is to change the phase of the junction’s traffic light(s) 12. The change urgency threshold Q defines a change activation level A _c above which the change drive 20A is in a state of urgency. And the change priority p is a value to which the change evaluation metric 24A is assigned while the change drive 20A is in a state of urgency. The junction cognitive manager 10 in this case may therefore determine whether the change drive 20A is in a state of urgency (Block 30A). If the change drive 20A is not in a state of urgency (NO at Block 30A), the junction cognitive manager 10 calculates the change evaluation metric 24A as a function f of the change activation level A _c , i.e., f(A _c ). For example, the junction cognitive manager 10 may calculate the change evaluation metric 24A as AJ2. On the other hand, if the change drive 20A is in a state of urgency (YES at Block 30A), the junction cognitive manager 10 calculates the change evaluation metric 24A as a function f of the change priority p, i.e., f(p). For example, the junction cognitive manager 10 may calculate the change evaluation metric 24A as 0.5 + p. In these and other embodiments, then, the change evaluation metric 24A may be calculated as a value between 0 and 1 , with the value being between 0.5 and 1 in a state of urgency and the value being between 0 and 0.5 not in a state of urgency.

Similarly, as shown in Figure 2B, the maintain drive 20B may be formed from multiple components that include a maintain activation level A _m , a maintain priority p, and a maintain urgency threshold Q. The maintain activation level A _m represents an intensity of the maintain drive 20B, e.g., so as to indicate how important the need is to maintain the phase of the junction’s traffic light(s) 12. The maintain urgency threshold Q defines a maintain activation level A _m above which the maintain drive 20B is in a state of urgency. And the maintain priority p is a value to which the maintain evaluation metric 24B is assigned while the maintain drive 20B is in a state of urgency. The junction cognitive manager 10 in this case may therefore determine whether the maintain drive 20B is in a state of urgency (Block 30B). If the maintain drive 20B is not in a state of urgency (NO at Block 30B), the junction cognitive manager 10 calculates the maintain evaluation metric 24B as a function f of the maintain activation level A _m , i.e., f(A _m ). For example, the junction cognitive manager 10 may calculate the maintain evaluation metric 24B as A 2. On the other hand, if the maintain drive 20B is in a state of urgency (YES at Block 30B), the junction cognitive manager 10 calculates the maintain evaluation metric 24B as a function f of the maintain priority p, i.e., f (p). For example, the junction cognitive manager 10 may calculate the maintain evaluation metric 24B as 0.5 + p. In these and other embodiments, then, the maintain evaluation metric 24B may be calculated as a value between 0 and 1 , with the value being between 0.5 and 1 in a state of urgency and the value being between 0 and 0.5 not in a state of urgency.

No matter the particular way in which the evaluation metrics 24A, 24B are generated, the junction cognitive manager 10 makes its decision 26 between changing the phase and maintaining the phase, based on the change evaluation metric 24A and maintain evaluation metric 24B. In some embodiments, for instance, the junction cognitive manager 10 decides to change the phase or maintain the phase depending respectively on whether the change evaluation metric 20A or the maintain evaluation metric 20B is larger. Having made the decision 26 between changing the phase and maintaining the phase, the junction cognitive manager 10 (e.g., via a controller 28) then controls the traffic light(s) 12 to change the phase or maintain the phase in accordance with that decision 26.

Note that in some embodiments, the junction cognitive manager 10 makes the decision 26 between changing the phase and maintaining the phase also based on one or more other metrics in addition to the change evaluation metric 24A and the maintain evaluation metric 24B. For example, in one or more embodiments as shown in Figure 1 , the junction cognitive manager 10 makes the decision 26 also based on a reactive behavior evaluation metric 24C and/or a random behavior evaluation metric 24D.

The reactive behavior evaluation metric 24C is an evaluation metric A _react for behaving reactively to the traffic situation at the junction 14. The junction cognitive manager 10 may for instance generate the reactive behavior evaluation metric 24C as a function of a traffic situation index TSI , e.g., which may quantify the traffic situation at the junction 14. For example, the traffic situation index may be a function of an average speed of vehicles in the lanes of the junction 14, e.g., such that the traffic situation index indicates less traffic at the junction 14 when the average speed is higher. The traffic situation index TSI in one such implementation may be computed as TSI = 1.0 - here S is the average speed of all

vehicles running in the controlled lanes of the junction 14 and S ^* is the maximum speed, e.g., arbitrated as 16.66 m/s. In other implementations, though, the traffic situation index may be a function of the average speed, a metric for occupancy of the lanes in the junction 14, the current phase time, and/or the number of vehicles in the lanes of the junction 14. Regardless, the reactive behavior evaluation metric 24C in some embodiments may be equal to the traffic situation index, i.e., A _react = TSI.

In any event, the junction cognitive manager 10 may use the reactive behavior evaluation metric 24C to generate a recommendation R _react that the phase be changed or maintained and then take the recommendation into account in making the decision 26. The recommendation may for instance be that the phase be changed if the reactive behavior evaluation metric 24C is greater than or equal to a reactive change threshold (e.g., 0.5), i.e., R _react = \ ^Trv ; ^e Rreac ^t ³ °· ⁵ -

^False otherwise.

The random behavior evaluation metric 24D provides a measure of randomness to the decision-making process. In some embodiments, the random behavior evaluation metric 24D is generated as an evaluation metric A _rand which is a function of a random parameter, e.g., A _rand = i ¹ ^ ^random · ^next ( ) ³ 0.999, | _n

tO otherwise.

any event, the junction cognitive manager 10 may use the random behavior evaluation metric 24D to generate a recommendation R _rand that the phase be changed or maintained and then take the recommendation into account in making the decision 26. The recommendation may for instance be that the phase be changed if the random behavior evaluation metric 24D is equal to a random change threshold (e.g., 1 .0), i.e., R _rand = \ ^True ^ ^{Arand ~ 1'0,} in this case, then, 0.1 % of

1 False otherwise.

the time the phase will be changed randomly.

Note further that the junction cognitive manager 10 in some embodiments may alternatively or additionally make the decision 26 based on whether one or more exceptional conditions dictate that the phase be changed or maintained. For example, such an exceptional condition may include an emergency vehicle (e.g., police car, ambulance, or fire truck) or other certain types of vehicles needing to traverse the junction. The junction cognitive manager 10 in one embodiment may make the decision 26 in order to always (i.e., unconditionally) allow the emergency vehicle to traverse the junction. In other embodiments, though, the junction cognitive manager 10 makes the decision 26 in order to allow the emergency vehicle to traverse the junction 14 only if one or more conditions are met. The condition(s) may for instance include that the traffic situation at the junction 14 is not deemed critical and/or that the minimum and maximum times for the traffic light(s)’ phases are met.

Figure 3 illustrates some embodiments for supporting such collaboration between the junction cognitive manager 10 and certain types of vehicles. As shown, certain types of vehicles are equipped or otherwise associated with a vehicle cognitive manager 32. The vehicle cognitive manager 32 of a vehicle is configured to transmit discovery signaling 34 to a coordinator cognitive manager 36. The discovery signaling 34 requests information indicating a junction cognitive manager 10 that controls one or more traffic lights 12 governing traffic at the junction 14 of roads which the vehicle is to traverse. The coordinator cognitive manager 36 correspondingly determines, based on the discovery signaling 34, which junction cognitive manager 10 controls the traffic light(s) 12 governing traffic at the junction 14, and transmits a discovery response 38 in return. The discovery response 38 indicates the determined junction cognitive manager 10. The vehicle cognitive manager 32 may then transmit, to the identified junction cognitive manager 10, a request 40 that requests collaboration with the junction cognitive manager 10 for traversing the junction 14. The request 40 may for instance request that the junction cognitive manager 10 make its decision 26 about the traffic light(s) phase so as to allow the vehicle to quickly traverse the junction 14.

Although the above embodiments were described with respect to a single junction 14, embodiments herein are extendable to any number of junctions. In fact, different junction cognitive managers may collaborate with one another for controlling the traffic light(s) that govern vehicular traffic at different respective junctions. In such embodiments, then, the decision 26 about whether to change or maintain the phase of traffic light(s) at a junction may also be based on a request for collaboration from a different junction cognitive manager that controls one or more different traffic lights at a different junction of roads. Such request may for instance request the junction cognitive manager 10 to control the phase of the one or more traffic lights 12 at the junction 14 in collaboration with the different junction cognitive manager’s controlling of the phase of the one or more different traffic lights at the different junction.

In some embodiments, then, each traffic junction has its own cognitive manager. The cognitive manager of a junction could either be embedded in the traffic junction itself or deployed in a cloud. The only parts that must necessarily be located at the traffic junction are sensors and actuators. A central system for identifying smart cars, and finding the closest cognitive manager relevant to it, may be implemented in the cloud.

More particularly with regard to implementation of the junction cognitive manager 10, the junction cognitive manager 10 in some embodiments has a cognitive architecture (e.g., a multipurpose enhanced cognitive architecture) that exploits so-called codelets and/or memory objects for this purpose.

Memory objects are any kind of data structure or wrapper used to store information and/or knowledge. A memory object has a type T, and an encoding of information I. This information can be a single measurement, expressed by a number, or a complex data container, which structure is completely defined by the definition of its type T.

Codelets are pieces of non-blocking code, executing a well-defined and simple task. The prototype of a codelet is a piece of code which ideally shall be executed continuously and cyclically, time after time, being responsible for the behavior of an independent component of a system running in parallel. In some embodiments, a kind of coordination exists among codelets, forming coalitions which by means of a coordinated interaction, are able to implement the cognitive functions ascribed to the architecture. This coordination constraint imposes special restrictions while implementing codelets in a serial computer. In a real parallel system, a codelet would simply be called in a loop, being responsible to implement the behavior of a parallel component.

According to some embodiments, a codelet has two main inputs including a local input (In) and a global input (B). The local input is used for the codelet to get information from memory objects, which are available at raw memory. The global input is used for the codelet to get information from a global workspace mechanism. Information coming from global workspace is variable at each instant of time, and is usually in the form of a summary, which works as an executive filter to select the most relevant pieces of information available in memory at each time-step. The two outputs of a codelet are a standard output (Out), which is used to change or create new information in the Raw Memory, and the activation level (A), which indicates the relevance of the information provided at the output.

With this understanding of codelets and memory objects, Figure 4 illustrates how the junction cognitive manager 10 evaluates different alternative motivational behaviors in parallel according to some embodiments. More specifically in this regard, Figure 4 shows that multiple behaviors provide different motor prescriptions for the same actuator X (e.g., for a phase of the light(s)). The different drives D1 , D2 and D3 in Figure 4 are used to produce three different memory

objects {Xi;Ei}, each one holding a pair with Xi being a motor signal and Ei being an evaluator (Eval) for the memory object (also referred to above as an evaluation metric). The Memory Container in the Motor Memory will be used to choose which motor signal Xi will be conveyed to the Motor Codelet (e.g., the one with biggest Ei).

In this case, the drives are memory objects generated by Motivational Codelets in two ways: i) directly from sensory variables or ii) derived from other existing drives in the agent. In the first case, drives are said to be of a primary type. In the second case, they are said to be of a secondary type.

If all the drives are functionally exactly the same, there might be situations in which the junction cognitive manager 10 might give preference to e.g. a social drive, like "social acceptance" instead to a physiologic drive like hunger. This is acceptable in a normal situation, but if both drives are in a state of“urgency", in which the system has a risk to collapse (as e.g. in a state of minimum energy), it is clear that the hunger drive must have some sort of priority, due to the potential harmful consequences to the system (if the system shuts down due to lack of energy, the social“urgency" has no meaning at all). To allow a special treatment in similar situations (e.g., of“emergency" or“urgency”, some embodiments include a special mechanism in the model of motivations. This special mechanism works as follows. Besides the activity level, or intensity, already associated to a drive, two more parameters are included: urgency threshold and priority as described above with respect to Figure 2B. The urgency threshold is a limit value for the activity level that, upon reaching this value, the drive is considered to be in a state of urgency. In this state of urgency, instead of using the activity level to select among different drives, the junction cognitive manager 10 must use a fixed priority assigned to the drive, which will warranty that the correct drive will win among motivated behaviors.

Figure 5 shows additional details of the junction cognitive manager 10 according to some embodiments. Each activity represents an independent thread which is called in a time-based (typically around 10ms) frequency. Each of these activities transforms a previous set of objects into a new set of objects, as represented in the figure. Each of these threads is called a codelet, and represents a small piece of non-blocking code, executing a well-defined and simple task. The idea of a codelet is of a piece of code which ideally shall be executed continuously and cyclically, time after time, being responsible for the behavior of a system's independent component running in parallel.

The Sense codelet is responsible for periodically grabbing information from the environment, filling up the following objects: CurrentPhase, Occupation, PhaseTime, QueuesSize, MeanSpeed and SmartCarlnfo. CurrentPhase identifies which of the phases is set in a given instant of time. Occupation measures the average occupation of all lanes in the junction, ranging from 0 to 100%. The occupation of each lane depends on the length of the lane, the number of cars waiting in the queue and the size of the cars. PhaseTime measures the amount of time since the last phase change. QueuesSize measures the number of vehicles in each lane. MeanSpeed measures the average speed of all vehicles crossing the junction. SmartCarlnfo receives messages from Smart Cars, informing their current position. If there is no Smart Car in the system, this input remains silent all the time.

The Changing Phase Drive Evaluation codelet calculates the Changing Drive, using for it part of the sensed variables, as detailed in Figure 5. The

Maintaining Phase Drive Evaluation codelet calculates the Maintaining Drive, based on the same information. The Situation Perception codelet encapsulates the following information obtained from the environment: the activation level (a value ranging from 0 to 1 representing how far the mean speed is from the average mean speed), the time when the current phase was set, the lane occupancies average, the lane vehicle numbers average and the lane mean speeds average.

The SmartCar Percept stores the position and velocity of all smart cars approaching the junction. If there is any smart car in the junction, the Attention codelet turns its information into the CurrentPerception, which is used by the Process Exceptional Rules codelet to propose Exceptional Recommendations (e.g. to give preference to the smart car).

The Change Traffic Light Appreciation behavior codelet proposes the junction cognitive manager 10 to change the phase, with a certain strength, based on the Changing Drive and the Exceptional Recommendation. The Maintain Traffic Lights Appreciation behavioral codelet proposes the junction cognitive manager 10 to maintain the actual phase, with a certain strength, based on the Maintaining Drive and the Exceptional Recommendation.

The React to Lanes Appreciation behavioral codelet suggests either a maintain or a change phase proposition, based on the Situation Percept and the Exceptional Recommendation. The Random Change Phase Suggestion, depending on the Exceptional Recommendation might suggest a change or a maintain proposition, in a random way. All the behaviors are proposed together with an activity level, which is used to define the final Change/Maintain Decision, which is sent to the actuators.

Figure 6 illustrates a high-level diagram of a motivational-based control system according to some embodiments, e.g., for implementing a junction cognitive manager 10.

In some embodiments, a junction cognitive manager 10 has a Multipurpose Enhanced Cognitive Architecture, MECA, e.g., as described below for an urban traffic controller.

More particularly, some embodiments present a Cognitive Manager for urban traffic control, built using MECA, the Multipurpose Enhanced Cognitive Architecture, a cognitive architecture, e.g., implemented in the Java language. The Cognitive Manager controls a set of traffic lights in a junction of roads based on information collected from sensors installed on the many lanes feeding the junction. The junction manager seeks to optimize the average waiting times for all the cars crossing the junction, while at the same time being able to provide preference to special cars (police cars or firefighters), called Smart Cars, and equipped with special devices that grant them special treatment during the phase allocation policies provided by the architecture. Simulation results provide evidence for an enhanced behavior while compared to fixed-time policies.

The general approach is to model the problem as a System of Systems (SoS). It is important to differentiate here a System of Systems from simply a System of Subsystems. Any traditional system can be understood as a system composed of subsystems or even a Family of Systems (FoS). Systems of systems, on the contrary, are not just a larger version of the same old hierarchical structure. A system of systems is“open at the top”,“open at the bottom” and“continually evolves - but slowly enough to be stable”. What characterizes an SoS is that new SoS parts are continuously joining and leaving the SoS, establishing a dynamic configuration to it, which easily might become very complex. Some embodiments propose that each part joining the SoS should be controlled by a Cognitive Manager, responsible for internally controlling its own subsystem, with its own performance measures, and externally interacting with the SoS, asking and offering collaboration to other peers in the SoS. The Cognitive Manager may be intelligent enough to decide how much to compromise, in its seek for optimization of its performance metrics, in order to collaborate with requests coming from other SoS peers, and also how much and when to ask for collaboration from other peers in order to enhance its own performance indexes.

Some embodiments are exemplified as a small SoS, composed by a set of Junction Cognitive Managers, each of them controlling the traffic lights of a single junction in a city topology, a Car Cognitive Manager, a simple smartphone application which can turn any car (in principle, special cars, like police or firefighters car) into a Smart Car, and a Coordinator Cognitive Manager, which receives Smart Car requests for special treatment, identifies a possible Junction Cognitive Manager which is close enough to the Smart Car in order to collaborate with it, and sends a reference of it to the Car Cognitive Manager. After that, the Car Cognitive Manager starts talking directly to the Junction Cognitive Manager and, if possible, the Junction Cognitive Manager might collaborate and give priority access to the Smart Car in its control of its traffic lights. In one implementation, both the Car Cognitive Manager and the Coordinator Cognitive Manager are simplified in order to allow for easier simulations. The Junction Cognitive Manager, though, in some embodiments is constructed using MECA. These embodiments show the potential of MECA for building other kinds of Cognitive Managers in other Smart Cities problems and evidence the convenience of using cognitive architectures like MECA to build and manage Systems of Systems. Experimental results show a decrease in waiting time which is comparable to other computational intelligence techniques, but due to use of a cognitive architecture, it is scalable to include in the future other enhancements, like the communication between neighbor traffic lights.

More particularly, a Cognitive Manager in some embodiments is a special kind of agent managing a set of physical objects made available at the Internet due to a process of virtualization. This virtualization consists in plugging-in physical objects from the real world to the Internet, allowing them to provide information about themselves and in some cases receiving commands meant to cause some change in the object internal state or a mechanical action in the physical world. A Virtual Object (VO) is then the representation of a physical object at the Internet, providing information about it and possibly allowing commands affecting its behavior in the physical world. In this sense, physical objects like cars, buses, trains, traffic lights, doors, ordinary lights, air conditioners, and many other devices might provide information and be (partially) remotely operated through Internet. Also, public spaces like gardens, parking places, stations, libraries, governmental offices, etc, might provide information such as images and sound, and have themselves be managed in terms of access control, environmental control and resource availability by the Internet.

Even though the existence of VOs brings an interesting scenario, allowing information to be grabbed from different objects at a city environment, in general the situation starts to become more interesting when many different VOs are mashed up into Composite Virtual Objects (CVO), which together provide some sort of functionality, like e.g. the urban traffic control of multiple traffic lights in a city environment. Each junction of streets/roads can be seen as a whole system of VOs, where each traffic light is a VO, each induction lop is also a VO, and all of them together can be seen as a CVO system. One important difference between standard VOs and CVOs is that usually a CVO has a dynamics in time, requiring some sort of control. In this sense, a CVO Manager usually employs control rules opening and closing traffic lights, such that the traffic might flow. These control rules might be fixed, and in such a case a CVO might only offer traffic statistics information, which might be useful for transit authorities. But these control rules may be adaptive, and in this case, the CVO Manager might accept requests for changing its control strategy, in specific cases. Now, considering an SoS scenario, different CVO managers might interoperate, requesting the collaboration of other systems. In some embodiments, for example, a CVO comprises the many systems available in a car, managed by a car CVO manager, and a junction of streets (traffic lights and induction loops on a crossroad), managed by a junction CVO manager. The car CVO manager may require the collaboration of the junction CVO manager to facilitate its passing through the traffic lights. The junction CVO manager may decide to collaborate or not with the car CVO manager, depending on its traffic conditions. In a light traffic situation, (or if the car is an emergency vehicle like an ambulance, or a police car), the junction CVO manager may change the traffic lights in order to facilitate the car crossing the junction with minimal delay. Also, neighbor junction CVO manages may exchange information requesting some sort of collaboration with their neighbors in order to dismiss a traffic jam.

The full specification for the behavior of a CVO manager can be, though, very challenging. To provide the standard properties expected from an SoS

(autonomy, belonging, connectivity, diversity and emergence) some sort of enhanced intelligence from the part of CVO managers may be necessary. Some embodiments solve this by making these managers cognitive.

The term cognitive here is used in association with a technology that operates inside a complex environment, observes it, makes behavior choices, and receives feedback from it, all the while learning - assembling a data set that will help determine future behaviors based on past and current feedback. This behavior might include interacting with other cognitive managers, asking for their help, and also attending requests for help from still other cognitive managers.

An example of such a scenario is presented in Figure 7. Here, different cognitive managers (CMs) join and leave the Smart City SoS. Some of these are continuously managing a set of VOs (e.g. a junction CM managing the different traffic lights and induction loops comprising a junction crossroad), with goals (e.g. the goal of minimizing the average trip time of all cars crossing the junction) and performance indexes (Pis) to meet (e.g. a traffic quality index being measured at each junction). A house CM may provide access control, air-conditioned control, illumination control, etc. Others, like car CMs, house CMs or people running their smartphones (which also work as CMs), may appear and disappear as required, entering and leaving the Smart City SoS and asking for collaboration regarding their own goals.

The construction of a Cognitive Manager in some embodiments requires a special strategy in order to provide cognitive capabilities to these managers. In some embodiments, these cognitive abilities can be gained with the aid of a cognitive architecture, in this case, the MECA Cognitive Architecture. A cognitive architecture can be viewed as a computational architecture suitable to bring cognitive abilities to an artificial agent. Cognitive architectures are developed using as a source of inspiration different models for cognitive capabilities human beings are know to possess, like perception, memory, internal representation of the external world and the ability to use this internal model to perform simulations predicting future scenarios, making plans of action and executing those plans in order to satisfy the system’s goals and/or other motivations.

The cognitive abilities required for a particular cognitive manager might depend on the VOs under their supervision, its goals and motivations, its performance indexes and its possibilities for acting out on the real world. Some implementations use the CST toolkit and the MECA cognitive architecture to construct a cognitive architecture shown in Figure 8A and Figure 8B.

A Cognitive Manager Designed with MECA

The MECA Cognitive Architecture provides many features for building cognitive capabilities into a CVO Manager. See, e.g., An Overview of the

Multipurpose Enhanced Cognitive Architecture (MECA), R Gudwin et al., Procedia computer science 123, 155-160 (2018). The exploitation of these features depends on the complexity envisioned for the manager. First of all, it is necessary to analyze the VOs managed by the CVO manager, in order to evaluate the potential information they are able to provide, and the possible commands which can be sent to them. This will allow the definition of the available Sensory and Motor Codelets to be included in MECA, together with the Memory Objects to be created by the Sensory Memory and those used as actuators by the Motor Codelets.

The Behavioral System

The MECA architecture is split by design into two separate but

complementary subsystems: System 1 and System 2, following cognitive models for dual-process theories. System 1 is responsible for specialized and automatic behavior, while System 2 is responsible for goal-based, deliberative behaviors. These two subsystems are intertwined, and the deliberations of System 2 are able to interfere with the automatic behaviors at System 1 , generating a hybrid overall behavior, partially automatic, partially deliberative. In MECA, System 1 is implemented by a Subsumption architecture, where three different kinds of behaviors are possible: (i) Random Behaviors; (ii) Reactive Behaviors; and (iii) Motivated Behaviors.

In Subsumption architecture, all behaviors are generated in parallel, and they compete with each other in order to have access to the actuators. So, at each time, all these three kinds of behaviors are generated, and evaluated given the actual situation and its context.

In simpler situations, where the CM must provide only a well-known automatic behavior, only Reactive Behaviors Codelets are necessary. Reactive Behaviors are those which can be determined by a simple function or algorithmic procedure over the inputs. So, the actuator values are calculated as a function of the sensory inputs. The CM designer must look at the Memory Objects at the Motor Memory and delineate the set of different behaviors which might be able to determine their value.

Different options might be considered. If different behaviors affect the same actuators, Container Memories might be used such that the many behaviors are allowed to compete and only the winner will be able to affect the Motor Codelets.

In some situations, Random Behaviors may be included, e.g., in cases where only Reactive Behaviors are not enough to generate a solution. In a Reactive Behavior, Codelets inputs are used to verify if the conditions for running the behavior are met. If these conditions are not met, the evaluation of the codelet outputs receives a very low score, such that the behavior is not chosen. In situations where no Reactive Behavior conditions are met, it might be unreasonable to have Random Behaviors generating an unexpected output.

This happens also in human behaviour. When we don’t know what to do, we start doing random moves, trying to move ourselves out of the stuck situation, such that we are able again to decide what to do. The use of Random Behaviors might move the system state to a different condition, where other Reactive Behaviors are suitable and then the system might recover for example from a repetitive behaviour where it got stuck.

Even though complex behaviors can be generated through the competition of Reactive Behaviors alone, there is a limit on what can be expected from only Reactive (and eventually Random) Behaviors. Reactive behaviors are blind. If the conditions for triggering them are met, they are executed, without any evaluation on the possible results to the system situation. If these conditions are well defined, Reactive Behaviors can be quite effective. But the meeting of any performance index is just a casual offspring of a fortunate set of behaviors, chosen on the possible outcomes of the system actions (or by learning, if a learning system is used to set up a set of reactive behaviors). The system, in itself, is not using any performance index for taking decisions. It is just reacting in a prescribed way, following a script given the sensed situation. Reactive Systems might be defined by a simple (or fuzzy) rule system, where rules match a condition into a given action, or similarly, using a neural network (e.g. a multi-layer Perceptron), where a learning system might be used to train this neural network.

In some embodiments, one or more performance indexes may be defined to be optimized. In MECA, these performance indexes can be used to determine a Motivated Behavior, giving rise to Drives. While in pure Reactive Systems, actions are chosen as a mere function of the sensed inputs, in Motivated Behavior, actions are chosen in order to optimize a Drive.

The concept of motivational behavior in CAs has its inspiration in studies about Human Motivation, realized in Cognitive Psychology. When a motor action is a pre-requisite to optimize the probability of survival of either an individual or a species, there is a state of needness. This need motivates or drives the associated motor action. So, a Drive is a variable used to characterize a need. Drives are used as a measurement of a performance index, which the creature must optimize, to survive. In a living being, a drive might be related to the many needs, such as the need for food, for water, for air, the need to avoid injury, to maintain an optimal temperature, the need to rest, to sleep, to mate, etc. In an artificial agent, drives are just performance indexes the agent must optimize, being directly associated with the desirable behaviors the agent is wanted to manifest. They are involved with a desirable future state for the agent, where drives values are minimized or maximized. So, a drive can be seen as the measurement of the agent’s success in achieving a purpose. Also, a behavior which is performed to satisfy a drive is said to be a motivational behavior or a motivated behavior.

Humans, animals or cognitive agents need to follow important criteria in daily activity to survive in any environment: sustainability, purposefulness, focus and adaptivity. Every agent must attend its physiological needs (sustainability), such as hunger, thirst, avoid physical dangers and others. Consequently, its actions must be based on its purposes, instead of a random choice (purposefulness). Besides that, it must focus its activities such that its needs and purposes are consistent, persistent and continuous (focus). However, there may be temporary or permanent situations in which the agent might enter into a state of urgency, while a special behavior might be appropriate. Finally, the agent must be able to adapt its behaviors according to the objectives to get the best results. These criteria facilitate understanding that motivational dynamics in animals or humans are a crucial part of composing a final behavior.

Both theories suggest that motivations are used as a reference signal in a feedback control system, guiding and optimizing human behaviors in order to achieve the best results considering its internal needs. Therefore, needs motivate humans and animals to decide the best choice of action these internal needs can be suppressed and a desired state reached.

The notion of drive is important for understanding another critical cognitive capability: emotions. There is an intrinsic relationship between motivations and emotions. There is no consensus about what emotions really are. Different approaches have different views for what they are and how to model them. For example, some understand emotions as“valenced reactions to events, agents, or objects, with their particular nature being determined by the way in which the eliciting situation is construed”. Others understand emotions as internal“alarms” which give a momentary emphasis to certain groups of signals. Still others distinguish between“emotions”, which affect the body and“feelings”, which are a cognitive introspection of emotion. Other authors have completely different views about what emotions are. For example, to some, emotions work like“amplifiers” for motivations, working as homeostatic processes related to physiological variables.

In MECA, drives are memory objects generated by Motivational Codelets in two ways: i) directly from sensory variables or ii) derived from other existing drives in the agent. MECA relies on B model of emotions where emotions are viewed as cognitive distortions on the map of drives, changing for a given time the relative intensity of the different drives on the system, amplifying some drives and decreasing the intensity of others. For that purpose, another parameter may be included in the conception of drive: emotional distortion, which is a value (positive or negative) which distorts the activity level of a drive, in order to prioritize the motivated behaviors. Emotional codelets are modulated by Moods. Moods are a kind of emotional state which is determined by Mood Codelets, based on sensory data acquired from the environment. Depending on being in a normal mood, or on an alternate mood like sleepy, worried, terrified, in love, etc., the emotional codelet might determine a cognitive landscape, making that a different priority is used to select motivated behavior.

According to some embodiments, then a drive is formalized as follows: A drive d is defined as a tuple d = {A, q, d, r} where:

• A is the activity level representing the intensity of the drive, A e [0, 1]

• Q is the urgency threshold such that if A > Q then the drive is in a state or urgency, q e [0,1].

• d is the emotional distortion which should be added to A in order to compute the intensity of the drive, d e [-1, 1] and 0 £ (A + 5) £ 1.

• p is the priority, p e [0, 0.5] , which is used to assign a fixed priority while in urgency mode.

Given the definition of drive the calculation of the Eval value in the Memory Objects (which are generated by the Motivational Behavioral Codelets) is computed in the following way according to some embodiments. The calculation of the Eval parameter of a Memory Object generated by a Motivational Codelet, should adopt the following criteria:

In some embodiments, while in normal mode, Eval will be a number between 0 and 0.5, while if in urgency mode, Eval will be a number between 0.5 and 1. Using this convention, there is a warranty that while in a state of urgency, the drive with the biggest priority will always be selected by the dynamic subsumption mechanism.

This is depicted in Figure 9.

If one or more performance indexes are available in the design of a CM, a Drive may be defined for each of the Pis and a corresponding Motivated Behavior which is supposed to increase or decrease the Drive, depending if the PI is supposed to be maximized or minimized.

System 2 causes an interference pattern in every behavior in System 1. According to the MECA architecture, System 2 is responsible for generating deliberative plans, which might interfere with System 1 Behaviors, in order to affect the actuators, and consequently the Motor Codelets. It is important to carefully fine tune how System 2 commands interfere with System 1 Behaviors. All the Behavior Codelets in System 1 , together with their Local Inputs, have a Global Input. In MECA, this Global Input comes from System 2, and holds the Next Action prescribed by the deliberative plans from System 2. This fine tuning is important, because there is the risk of either System 2 or System 1 to systematically win the competition and suppress the effect of the other subsystem. If System 2 always has priority, it might just“turn-off the effect of System 1 , and work as a simple deliberative system. Otherwise, if System 2 is never allowed to win the competition, it is like it doesn’t exist in the overall system. A good tune might give preference to System 1 and in exceptional situations allow System 2 to take control.

Some embodiments then use System 1 as the default controller, handling most of the decisions in the determination of actions, while in normal operational conditions. System 2 is actioned only while exceptional conditions are detected, requiring an exceptional intervention. One example of such a duality in a Cognitive Manager might occur while trying a local optimization (managed by System 1 behaviors), when a call for a global optimization comes from another Cognitive Manager communicating with the current CM. This call for collaboration, in being an exceptional situation, is handled by System 2 according to some embodiments. System 2 then analyzes its availability for collaboration, based on the current status of its performance indexes, and decides if it is able to collaborate. If its performance indexes allow, it might decide to collaborate, even though at the cost of a decreasing in its performance indexes, with the hope of improving the performance indexes of its solicitor, and with that improving some global (or higher level) performance index. If its performance indexes are in a poor condition (e.g. in a worse condition than those of its solicitor), the system might deny collaboration and System 1 orders should prevail.

The Perception System

The Perceptual System prepares the information necessary for the

Behavioral System to perform its decision-making. Usually, the information coming from Sensory Codelets refers to Quality Dimensions collected from sensors, and related to physical properties of environmental objects. In some situations, these Quality Dimensions are enough for supporting decision-making by the Behavioral Codelets. In this case, there is no requirement for further abstractions. This data can be directly used by Behavioral Codelets as they come. But in more complex cases, like those requiring human understanding of complex situations, further abstractions are necessary. The Perception System is the sub-system within a Cognitive Architecture responsible for performing further abstractions, creating more elaborated representations which better describe the environmental situation.

In some embodiments, the Perceptual Codelets is responsible for creating the representational entities required for further processing. In some embodiments, MECA uses SOAR as a planning system in System 2. In this sense, the many concepts generated by the Perceptual System will be converted to WMEs in order to be processed by SOAR, and after SOAR makes a decision, the resulting WMEs might be turned into appropriate Memory Objects in order to affect System 1 behaviors.

In some embodiments, Attention Codelets select important concepts in the Perceptual Memory and copy them to the Working Memory, so that they can be used in System 2.

Depending on the situation, Episodes may be constructed from Current Perception and stored at the Episodic Memory. In some embodiments, the episodes re-called from the Episodic Memory might be used in the deliberative process.

The Working and Procedural Memories

In MECA, the design of both the Working Memory and the Procedural Memory are tied together. This occurs because MECA uses SOAR as its planning and execution system. This design starts with defining the format of the Next Action which is sent down to System 1 to interfere with the Behavior Codelets. Next, the designer must define the required input collected from System 1 Perceptual Memory and transformed into WMEs within SOAR’s input link. Finally, the designer must develop the rules in the Procedural Memory.

CMS for Urban Mobility

The general concept of a Cognitive Manager presented above is illustrated now in the context of urban mobility in a smart city.

A smart city infrastructure can be seen as the construction of an SoS, where different services can be provided by the virtualization of physical objects from the real world (through cyber-physical systems) and their possible interaction in mashes forming CVOs which can be locally controlled by a CVO manager. Cognitive abilities may be given to these managers, turning them into Cognitive Managers, and these cognitive abilities might be constructed with the aid of cognitive architectures (e.g. MECA). This is exemplified below with a set of cognitive managers that are constructed with MECA to interact and solve a common problem in urban traffic control, under the general scenario of a Smart City SoS.

The Urban Traffic Control Problem

In the overall SoS scenario, physical assets from the real world are virtualized into VOs and managed by a CM. Some VOs might occupy a fixed location in the real world, like e.g. traffic lights or induction loops, and other VOs might move around, like e.g. cars traveling into the urban environment or people carrying their smartphones. As a general rule, even though the communication of two VOs is possible, in order to provide more flexibility it may be assumed that only CMs are supposed to interoperate, asking for collaboration and receiving requests for service to be delegated to their VOs. In some particular situations, a CM may manage just one single VO. The role of the CM, in this case, is to enhance the VO with cognitive abilities (e.g., with the ability to dialog, integrating it into the SoS scenario of a Smart City).

It may be assumed that one major CVO integrates a controlled junction at an urban topology. In this case, the junction might have multiple traffic lights (each of them having its own VO), and sensors capable of providing information regarding the traffic running on the many lanes crossing the junction. A unique CM, the Junction Manager, controls the junction, operating the traffic lights and joining the junction in the Smart City SoS. An example of such a junction can be seen in Figure 10.

The junction depicted in Figure 10 has 16 lanes in 4 different edges, being L2-L4, L6-L8, L10-L12 and L14-L16 controlled lanes (because the traffic lights might command a stop on their flow), and L1 , L5, L9 and L13 are uncontrolled lanes (because they just receive the flow coming from other lanes - they do not generate traffic in themselves).

The situation described in Figure 10 also shows a particular phase in the traffic lights, where L6 and L14 are open to traffic, and all the other lanes are closed. The traffic coming from L6 can either go to L1 or to L5. The traffic coming from L14 can either go to L9 or L13.

The design of just a single junction like this can be quite complicated, where a set of phases must be precisely defined in order to not allow the crossing of traffic flows, and each junction has its specific set of phases and a typical sequence of phases, which must usually be enforced by law. This means that the CM controlling the junction cannot arbitrarily assign traffic lights, or choose random phases at any time. There is also a minimum and maximum time that each phase must attend. Figure 1 1 shows a little more elaborated case, with 2 junctions: West and East. Junction West has 4 different phases (as indicated in the figure) and junction East has only 3. The sequence of phases, in each case, must be obeyed.

In some embodiments, a junction cognitive manager locally controls each junction in a given topology, based on sensed information of traffic conditions in all the controlled lanes of the junction, and at each instant of time, decides if the junction should maintain its current phase or change to the next one in the prescribed sequence of phases for the junction, respected the minimum and maximum times allowed for each phase.

Some embodiments also include a second CM, the SmartCar Cognitive Manager, possibly an ambulance or a police car, which given its urgency in passing through the traffic lights, requests the collaboration of the Junction CM in changing its phase such that it might wait the minimum amount of time for crossing the junction. As soon as the SmartCar CM joins the Smart City SoS, it starts collaborating with a Localization CM, passing to it its current position, and if this position is close enough to the position of a junction controlled by a Junction CM, the Localization CM returns the Junction CM address to the SmartCar, and the SmartCar starts sending its position directly to the Junction CM.

The Junction Cognitive Manager

The architecture of a Cognitive Manager for a junction CVO, constructed with the aid of MECA can be seen in Figure 12.

The role of the Junction CM is to decide, at each time instant, if the junction should maintain its current traffic lights phase or change to the next phase. The junction CM is constructed with the aid of MECA, even though not all MECA modules are used in this example. Basically, System 1 is used to provide a decision under normal conditions, where the junction wants to locally minimize the average travel time of all the cars crossing it. For that purpose, a motivational system has two drives in this example: the change drive and the maintaining drive, which from their perspective might evaluate, at each time, the pressure to maintain or to change the current phase, based on the statistics they collect. In the example Junction CM, the role of System 2 is to analyze requests from SmartCars and if it is the case, to take the decision to collaborate with the SmartCar CM and change its behavior in order to minimize its travel time. It is important to emphasize that this has a cost, and will most likely make average travel time worse for all other vehicles. System 2 needs to decide what is feasible or not. If it has margins for that, i.e., it is not detecting a critical condition in the traffic flow, it will be more open to collaborate, but if the traffic conditions are critic, then it might decide not to collaborate. This policy, of course, is configurable, so it is possible, in principle, to always honor the request of a SmartCar.

Consider now the details of the Junction CM.

Sensor and Actuator Codelets

Real world traffic may be simulated with SUMO urban traffic simulator. For this purpose, sensor and actuator codelets are socket connections to SUMO using the TraCI protocol to interact with SUMO, acquire the required information and send the control signals to change the traffic lights phases. Depending on the simulation scenario, many junction CMs may be run, one for each controlled junction in the scenario.

In a realistic case scenario, only input information from inductive loops installed in the junction may be used. This, however, restricts the possibilities of decision-making. In SUMO, there is the possibility of knowing the position of each car in each of the lanes. Even though it is not fully realistic to have this information in a real case (at least while cars are not enforced to provide this information by law), it is not unfeasible to have this information sometime in a near future. Therefore, the following information is collected by each junction in some embodiments:

Occupation: Average of the occupation of all lanes in the junction, ranging from 0 to 100%. The occupation of each lane depends on the length of the lane, the number of cars waiting in the queue and the size of the cars.

Phase Time: The amount of time since the last phase change.

Number of Vehicles: The number of vehicles in all lanes.

Average Speed: The average speed of all vehicles crossing the junction.

Smart Car Info: This input receives messages from Smart Cars, informing their current position. If there is no Smart Car in the system, this input remains silent all the time.

There is just one Motor Codelet in the Junction CM. It receives information from a boolean Memory Object commanding the junction to maintain the current phase or to switch to the next phase. The Maintain/Change boolean Memory Object is modeled by a Memory Container (represented in Figure 12 by a circle with a double line). This is necessary because many different behaviors might propose different actuations. A Memory Container is a special resource provided in CST to allow the Dynamic Subsumption mechanism to choose the proposal with the highest evaluation to be considered and commanded to SUMO. This is performed by the associated Motor Codelet.

The Behavioral Subsystem

The repertoire of behaviors in System 1 can be seen in Figure 13. The behavioral subsystem provides 4 different behaviors proposing a maintain/change decision for the next phase, which might compete with each other:

• 2 Motivational Behaviors: Change Phase and Maintain Phase

• 1 Reactive Behavior: React To Lanes Situation

• 1 Random Behavior: Random Change

Random Behavioral Codelet

In the example Junction CM, the role of Random Behavioral Codelet is to provide a measure of randomness to the decision-making process. In some embodiments, the activation A _rand of the Random Behavioral Codelet is calculated according to the following criteria:

) > 0.999,

In some embodiments, the recommendation R _rand given by the Random Behavioral

Codelet deciding if the Motor Codelet should change or not the current phase is based on its activation according to the following rule:

_R — (True if A _rand = 1.0,

r ^a n ^d . \p _aise otherwise

The practical effect is that in only 0.1 % of the cycles the Random Behavioral Codelet will write to the Motor Codelet determining the change of the current phase. This value was completely arbitrary, and included just to insert some level of randomness in the system.

Reactive Behavioral Codelet

The logic behind the Reactive Behavioral Codelet is that, based on a Traffic Situation Index used as input, it should determine a change in the phase. In some embodiments, the Reactive Behavioral Codelet’s activation is always determined by the traffic situation index TSI coming from the Situation Perceptual Codelet.

^react ⁼ {TSI.

The recommendation given by the Reactive Behavioral Codelet deciding if Motor Codelet should change or not the current phase is based on the following rule: 0.5

The practical effect is that everytime the traffic situation index is greater than 0.5, the Reactive Behavioral Codelet will prescribe the Motor Codelet to change the current phase.

Motivational Behavioral Codelets

The example Junction CM uses two Motivational Behavioral Codelets: the Change Traffic Lights, which always propose a change in the phase, and the Maintain Traffic Lights, which always propose to maintain the current phase. The activation of these codelets is determined by the Drives which are used as input to them, given by the Motivational Subsystem.

The Motivational Subsystem

The main role of the Motivational Subsystem is to calculate the drives to be sent to the Motivational Behavioral Codelets. The example Junction CM uses two drives: the Changing Drive and the Maintaining Drive. This is shown on the top of Figure 14.

In order to calculate those Drives, the example Junction CM has basically two motivational codelets: the Changing Motivational Codelet and the Maintaining Motivational Codelet. These codelets receive the many parameters affecting the junction situation and integrate them into two drives: The Changing Drive and the Maintaining Drive. The definition of a drive implies in the determination of the following parameters associated to the drive: (i) Activation; (ii) Urgency Threshold; and (iii) Priority.

In order to compute the drives activation, the motivational codelets employ an heuristics using both the Phase Time ( Q ), the time since the last change in phase and the AO , the difference between the average occupancy in all the lanes of the joint, computed in intervals of 8 seconds. If the Phase Time is less than the minimum phase time specified for the junction, the phase must be maintained (by specification). If AO is negative (or zero), this means that the traffic conditions are well balanced, and then the Maintaining Drive should be high, such that the phase should be maintained as is. If AO is positive, though, this means that the traffic conditions are becoming worse, and there is less and less indications that the phase should be maintained, and so the Maintaining Drive activation should decrease as long as time passes. Finally, if the phase time is greater than the maximum phase time specified for the junction, there is no more reason to maintain the phase, and then the drive should be set to 0. The definition below formalizes this. In particular, the activation A _m of the drive generated by the Maintaining Motivational Codelet is calculated by:

where Q is the current Phase Time, 0 _* is a constant that defines the Minimum Phase Time of the junction (8 seconds), 0 _* is a constant that defines the junction’s

Maximum Phase Time (120 seconds), and AO is the difference between the average occupancy over all lanes in the junction, computed on intervals of 8 seconds.

The activation of Changing Drive follows the same basic principles, formalized as: the activation A _c of the drive generated by the Changing Motivational Codelet is calculated by:

The Priority and Urgency Threshold of both drives are specified in Table 1.

Table 1 : Drives’ parameter The Perception Subsystem

Perception systems have the role of computing abstractions on the input sensory information, creating derivate knowledge which might be necessary for further processing in the cognitive system. In the example Junction CM, there are two different Perceptual Codelets. The first one is the Situation Perceptual Codelet, which was already seen in Figure 14. This Perception Codelet uses as input the occupation of all the lanes in the junction, the current phase time, the number of vehicles in all the lanes and the average speed in all the lanes and calculates a Traffic Situation Index for the junction. Even though all this information is available, the current implementation uses only the average speed of all the cars crossing the junction. The logic behind that is that the faster the cars are in the controlled lanes, the lower is the traffic situation index, signalizing a low traffic, a situation opposite to a traffic situation with an index closer to 1.0, where traffic is heavy. In some embodiments, the Situation Perceptual Codelet calculates the traffic situation index TSI based on the following rule:

min(S, S ^* )

TSI = {1.0 -

S*

Where S is the average speed of all the vehicles running in the controlled lanes of the junction and S ^* is the maximum speed, arbitrated as 16.66 m/s.

The other Perceptual Codelet is responsible for preparing information to be used by System 2, as shown in the bottom of Figure 14. It creates a representation for a Smart Car, if one is present.

The System 2 Subsystem

The role of System 2 in the example Junction CM is to evaluate collaboration requests from Smart Cars and decide if the CM is able or not to collaborate with the Smart Car and change the traffic lights in a way that could minimize the travel time for the Smart Car, without disturbing too much the other vehicles. From an operational point of view, this task is delegated to SOAR, as pointed out in Figure 15.

Consider a simple example where the Smart Car is an exceptional situation that must always be attended. The only restrictions, which must be followed, though are related to the minimum and maximum times for staying in a given phase. If the Smart Car arrives before the minimum time in the phase is reached, it will have to wait until this minimum time before it can be switched to the next one. This includes the minimum time holding for all the phases with a red light before one with a green light can be set. Figures 16-20 present schematic situations being encoded into rules for addressing this situation.

Figure 16 illustrates the situation covered in Rule 1 , in which the Smart Car (drew as an ambulance in the figures) is arriving in a lane where the current phase is enforcing a red light, and the expected time of arrival (given the current Smart Car velocity) in the junction is less than the maximum phase time but greater than the minimum phase time. Then the rule proposes the phase to change, in order to switch the lane to a green light.

Figure 17 illustrates the situation covered by Rule 2, in which the Smart Car is arriving in a lane where the current phase is enforcing a red light, but the expected time of arrival is less than the minimum phase time. In this case, the system proposes to maintain the junction in its current phase. Figure 18 illustrates the situation covered by Rule 3, in which the Smart Car is arriving in a lane where the current phase is enforcing now a green light, and the expected time of arrival is less than the maximum phase time. In this case, the rule suggests the system to maintain in the current phase.

Figure 19 illustrates the situation covered by Rule 4, in which the Smart Car is arriving in a lane where the current phase is enforcing a green light, but the expected time of arrival is greater than the maximum phase time. In this case, the rule suggests the system to change to the next phase.

Finally, Figure 20 deals with the case of no Smart Car present in the scenario. In this case, the rule suggests a <null> command to be generated. A <null> command signalizes the Behavior codelets in System 1 to follow System 1 prescriptions instead of System 2 commands.

The Smart Car Cognitive Manager

In some embodiments the Smart Car CM contacts a Location CM, with the knowledge of all Junctions in the city able to receive a collaboration message, and if the Smart Car is within a range from Junction CM, it gives this information to the Smart Car and the Smart Car starts to send its position to the Junction CM, such that the collaboration is suitable to happen.

According to some embodiments, the Junction CM is able to provide a fair service, providing the collaboration with Smart Cars when this is necessary. The choice of MECA as the cognitive architecture to implement cognitive abilities allows the scalability of the problem-solving strategy. It is just a matter of obtaining more inputs (e.g. information from neighbor junctions), followed by further behaviors, either in System 1 or in System 2, in order to enhance the Junction CM abilities, e.g., to address interference between junctions.

In some cases, the architecture may implement learning mechanisms, as e.g. using reinforcement learning techniques (like deep learning), to evaluate different control strategies and allow the system to test different strategies and learn the performance of them.

Some embodiments thereby include a method for dealing with the complex scenario of traffic control by reducing travel time, occurrence of traffic jams and, consequently, pollution emissions. The motivational system may be implemented in such a way that it is able to give priority to specific vehicles.

In view of the above modifications and variations, Figure 21 depicts a method performed by a junction cognitive manager 10 (e.g., as hosted by host equipment) for controlling one or more traffic lights 12 that govern vehicular traffic at a junction 14 of roads 16A, 16B in accordance with particular embodiments. The method may include obtaining a change drive 20A characterizing a need to change a phase of the one or more traffic lights 12 and a maintain drive 20B characterizing a need to maintain the phase (Block 21 10). In some embodiments, for example, the change drive 20A and the maintain drive 20B are based on traffic conditions at the junction 14 as sensed by one or more sensors 18. Regardless, the method my further include generating a change evaluation metric 24A and a maintain evaluation metric 24B as a function of the change drive 20A and the maintain drive 20B, respectively (Block 2120). In some embodiments, the change evaluation metric 24A indicates an importance of changing the phase for satisfying the change drive 20A and the maintain evaluation metric 24B indicates an importance of maintaining the phase for satisfying the maintain drive 20B. The method as shown may also include making a decision 26 between changing the phase and maintaining the phase, based on the change evaluation metric 24A and the maintain evaluation metric 24B (Block 2130). In some embodiments, the method may further include controlling the one or more traffic lights 12 to change the phase or maintain the phase in accordance with the decision 26 (Block 2140).

In some embodiments, the change drive includes a change activation level representing an intensity of the change drive, a change urgency threshold defining an activation level above which the change drive is in a state of urgency, and a change priority to which the change evaluation metric is assigned while the change drive is in a state of urgency. Alternatively or additionally, in some embodiments, the maintain drive includes a maintain activation level representing an intensity of the maintain drive, a maintain urgency threshold defining an activation level above which the maintain drive is in a state of urgency, and a maintain priority to which the maintain evaluation metric is assigned while the maintain drive is in a state of urgency. In some of these embodiments, generating the change evaluation metric comprises calculating the change evaluation metric as a function of the change priority if the change drive is in a state of urgency and as a function of the change activation level if the change drive is not in a state of urgency. Alternatively or additionally, generating the maintain evaluation metric comprises calculating the maintain evaluation metric as a function of the maintain priority if the maintain drive is in a state of urgency and as a function of the maintain activation level if the maintain drive is not in a state of urgency. In some embodiments, making the decision comprises deciding to change the phase or maintain the phase depending respectively on whether the change evaluation metric or the maintain evaluation metric is larger.

In some embodiments, the traffic conditions on which the change drive and the maintain drive are based include a difference between average occupancy in all lanes of the junction.

In some embodiments, the change drive and the maintain drive are also based on whether a current phase of the one or more traffic lights complies with a constraint on a minimum time for which any phase of the one or more traffic lights must be maintained and/or a constraint on a maximum time for which any phase of the one or more traffic lights is permitted to be maintained.

In some embodiments, the method further comprises generating a reactive behavior evaluation metric as a function of a traffic situation index and generating, based on the reactive behavior evaluation metric, a reactive behavior

recommendation that recommends the phase be changed or maintained. For example, in one embodiment, the traffic situation index is a function of an average speed of vehicles in lanes of the junction. Regardless, in this case, making the decision comprises making the decision also based on the reactive behavior evaluation metric and the reactive behavior recommendation.

In some embodiments, the method further comprises generating a random behavior evaluation metric as a function of a random parameter and generating, based on the random behavior evaluation metric, a random behavior

recommendation that recommends the phase be changed or maintained. In this case, making the decision comprises making the decision also based on the random behavior evaluation metric and the random behavior recommendation.

In some embodiments, making the decision comprises making the decision also based on whether one or more exceptional conditions dictate that the phase be changed or maintained. In one embodiment, for example, the one or more exceptional conditions include an emergency vehicle needing to traverse the junction. In this case, then, the method may further comprise receiving a request for collaboration from a vehicle cognitive manager of the emergency vehicle requesting collaboration with the junction cognitive manager for traversing the junction.

In some embodiments, making the decision comprises making the decision also based on a request for collaboration from a different junction cognitive manager that controls one or more different traffic lights at a different junction of roads. The request for collaboration may request the junction cognitive manager to control the phase of the one or more traffic lights at the junction in collaboration with the different junction cognitive manager’s controlling of the phase of the one or more different traffic lights at the different junction.

In some embodiments, the junction cognitive manager has a Multipurpose Enhanced Cognitive Architecture, MECA.

In some embodiments, the method further comprises collecting, by one or more sensory codelets of the junction cognitive manager, sensor data sensed by the one or more sensors and populating the sensor data in sensory memory of the junction cognitive manager.

In some embodiments, the method further comprises generating, by a changing motivational codelet of the junction cognitive manager, the change drive and generating, by a maintaining motivational codelet of the junction cognitive manager, the maintain drive.

In some embodiments, the change evaluation metric is generated by a changing behavioral codelet of the junction cognitive manager and the maintain evaluation metric is generated by a maintaining behavioral codelet of the junction cognitive manager.

In some embodiment, the method further comprises writing the decision in a Boolean memory object of the junction cognitive manager that commands a motor codelet of the junction cognitive manager to change the phase or maintain the phase. In this case, controlling is performed by the motor codelet according to the command from the Boolean memory object.

Figure 22 depicts a method performed by a coordinator cognitive manager 36 (e.g., as hosted by host equipment) in accordance with other particular embodiments. The method may include determining, based on control signaling 34 received from a vehicle cognitive manager 32 of a vehicle, a junction cognitive manager 10 that controls one or more traffic lights 12 governing traffic at a junction 14 of roads 16A, 16B which the vehicle is to traverse (Block 2210). The method may further include signaling 38 information to the vehicle cognitive manager 32 indicating the determined junction cognitive manager 10 (Block 2220).

Figure 23 depicts a method performed by a vehicle cognitive manager 32 of a vehicle in accordance with other particular embodiments. The method may include transmitting signaling 34 to a coordinator cognitive manager 36 requesting information indicating a junction cognitive manager 10 that controls one or more traffic lights 12 governing traffic at a junction 14 of roads 16A, 16B which the vehicle is to traverse (Block 2310). The method may also include receiving from the coordinator cognitive manager 36 a response 38 including the requested information (Block 2320). The method may further include transmitting to the indicated junction cognitive manager 10 a request 40 for collaboration requesting collaboration with the junction cognitive manager 10 for traversing the junction 14 (Block 2330).

Note that the apparatuses described above may perform the methods herein and any other processing by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random- access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

Figure 24 for example illustrates host equipment 2400 configured to host a junction cognitive manager 10 as implemented in accordance with one or more embodiments. As shown, the host equipment 2400 includes processing circuitry 2410. The host equipment 2400 in some embodiments also includes communication circuitry 2420. The communication circuitry 2420 is configured to transmit and/or receive information to and/or from one or more other cognitive managers or sensors, e.g., via any communication technology. The processing circuitry 2410 is configured to perform processing described above (e.g., in Figure 21), such as by executing instructions stored in memory 2430. The processing circuitry 2410 in this regard may implement certain functional means, units, or modules (e.g., for performing respective steps in the method of Figure 21). Figure 25 illustrates host equipment 2500 configured to host a coordinator cognitive manager 36 as implemented in accordance with one or more

embodiments. As shown, the host equipment 2500 includes processing circuitry 2510. The host equipment 2500 in some embodiments also includes communication circuitry 2520. The communication circuitry 2520 is configured to transmit and/or receive information to and/or from one or more other cognitive managers or sensors, e.g., via any communication technology. The processing circuitry 2510 is configured to perform processing described above (e.g., in Figure 22), such as by executing instructions stored in memory 2530. The processing circuitry 2510 in this regard may implement certain functional means, units, or modules (e.g., for performing respective steps in the method of Figure 22).

Figure 26 illustrates host equipment 2600 configured to host a vehicle cognitive manager 32 of a vehicle as implemented in accordance with one or more embodiments. As shown, the host equipment 2600 includes processing circuitry 2610. The host equipment 2600 in some embodiments also includes communication circuitry 2620. The communication circuitry 2620 is configured to transmit and/or receive information to and/or from one or more other cognitive managers or sensors, e.g., via any communication technology. The processing circuitry 2610 is configured to perform processing described above (e.g., in Figure 23), such as by executing instructions stored in memory 2630. The processing circuitry 2610 in this regard may implement certain functional means, units, or modules (e.g., for performing respective steps in the method of Figure 23).

Note that in at least some embodiments host equipment 2400, 2500, and/or 2600 is distributed across multiple physical nodes, machines, or other hardware, e.g., in a cloud environment or a virtualized environment. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines or containers executing on one or more physical processing nodes in one or more networks). In some embodiments, some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments hosted by one or more of hardware nodes. Those skilled in the art will also appreciate that embodiments herein further include corresponding computer programs.

A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

Embodiments further include a carrier containing such a computer program. This carrier may comprise one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

In this regard, embodiments herein also include a computer program product stored on a non-transitory computer readable (storage or recording) medium and comprising instructions that, when executed by a processor of an apparatus, cause the apparatus to perform as described above.

Embodiments further include a computer program product comprising program code portions for performing the steps of any of the embodiments herein when the computer program product is executed by a computing device. This computer program product may be stored on a computer readable recording medium.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure. Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the description.

The term unit may have conventional meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, modules, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.

Some of the embodiments contemplated herein are described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.