CBTC - General Discussion

[Jcb]

I notice that CBTC is increasingly described as the technology that fixes any operation and/or speed issues on the subway. I feel , at risk of great oversimplification, that a more efficient operating environment would fix a lot of capacity issues:

• Reprogram NTT motors to accelerate faster and to higher speeds
• Loosen penalties for operators that trip timers while traveling at the posted speed
  • Only if it can be proven that they were traveling at or below said speed
• Decrease braking distances and control lengths
• Survey every timer in the system and evaluate which are truly necessary for safety
• Assign each dispatch tower a permanent crew so that they can learn the patterns of their designated area for efficiency's sake
• Use local recycle on NTTs instead of reopening the entire set

Honestly these are a lot easier said than done, but they would probably cost less than and be faster to implement than CBTC for some temporary relief from our current situation. 

• On an unrelated note, connecting IND Fulton St and Montague with SAS provisions would probably be a quick solution for Cranberry's issues

 

Edited December 6, 2018 by Lance

[RR503]

I think you raise excellent points. Folks here are probable bored of me advocating for those changes, so glad you bring them up. (If I may, double ending at all terminals, dispatcher centralization, and the implementation of gap trains should be on that list.)

More generally, I think the question with it is less “is it necessary” and more “can we know it’s necessary (or act in good faith) without having made the current system perform as best as it can.” To paraphrase my signature, operational disasters like ours demand operational solutions. I think it’s a testament to the power of technology in the modern psyche that seemingly everyone has decided that CBTC will save us. 

Edited October 31, 2018 by RR503

[Lance]

While there are major operational issues that need to be addressed (timer placement, fumigation, etc.), the problem itself is two-fold. The other half of the problem is the positively ancient signaling system that's in place. While those ideas mentioned above are a good start for fixing the bulk of the issues short-term, as a long-term goal, the signal system has to be replaced regardless. Whether that's through the CBTC system or other conventional signaling depends on who's asked and possible location. On the subject of CBTC itself, perhaps it's an over-reliance on computers to run trains these days, but the fact remains that several major transit agencies worldwide have shifted over to this particular system, which should be a testament to its benefits, despite the costs involved. Either way, we cannot hope to resolve all of the problems plaguing the subway's operation by simply removing the operational hurdles. We have to fix the underlying problem as well.

[Lawrence St]

4 minutes ago, Lance said:

While there are major operational issues that need to be addressed (timer placement, fumigation, etc.), the problem itself is two-fold. The other half of the problem is the positively ancient signaling system that's in place. While those ideas mentioned above are a good start for fixing the bulk of the issues short-term, as a long-term goal, the signal system has to be replaced regardless. Whether that's through the CBTC system or other conventional signaling depends on who's asked and possible location. On the subject of CBTC itself, perhaps it's an over-reliance on computers to run trains these days, but the fact remains that several major transit agencies worldwide have shifted over to this particular system, which should be a testament to its benefits, despite the costs involved. Either way, we cannot hope to resolve all of the problems plaguing the subway's operation by simply removing the operational hurdles. We have to fix the underlying problem as well.

I don't like CBTC because it relies on computers instead of human hands. While it works great for the  and because they're isolated, it won't work for the others because of the complexity. 

[Jcb]

It's kind of interesting how everyone settled on CBTC as the answer. Although it absolutely has its merits, are there any examples of it scaling up to a system with as much interlining and possibility of reroute?

 

In the interim, though, the MTA has been given lemons. They aren't making the lemonade that they could be. 

[rbrome]

1 hour ago, Lawrence St said:

I don't like CBTC because it relies on computers instead of human hands. While it works great for the  and because they're isolated, it won't work for the others because of the complexity. 

You're saying that 100-year-old technology is better suited to a very complex system than modern computer technology? That doesn't even begin to make sense. 

The old signal system relies on (mechanical) parts that are inevitably prone to wear and breakdowns, something we've all experienced. CBTC is solid-state, which can be far more reliable (when designed correctly) and can include self-diagnostic features so problems can be identified and fixed much faster. Ideally the MTA would move to 100% CBTC as quickly as possible, and benefit from vastly improved reliability overall. 

[CenSin]

On top of CBTC, they should get articulated trains. That way, if the MTA must keep its insane rules, it will at least have technology to remove the human elements that caused those rules to be put in place.

• Trains may not touch the platform until it can platform completely. Usually, that means waiting until the train ahead has left the station entirely. With articulated trains, people cannot jump off the train between cars anyway, so the MTA can platform halfway without worrying about legal liabilities.
• Articulated trains also remove the need to police people crossing between cars.
• Trains have a huge margin of error for braking due to the varied performance characteristics of the train and the human operator. CBTC makes the variation in performance go away and thus, closes the gap between trains to the safest level allowable by physics.
• CBTC can potentially be hooked up to sensors sprinkled throughout the system, acting on the data in real time, whereas a train operator can only operate on line of sight and things that come in over the radio. Sensors could detect people on the tracks, debris, and other conditions.
• CBTC can potentially open up real time maps of where every train is and their statuses—what GPS did for buses.

[N6 Limited]

11 hours ago, Jcb said:

Loosen penalties for operators that trip timers while traveling at the posted speed

• Only if it can be proven that they were traveling at or below said speed

 

If the speed limit is 25 and the T/O was going 27 there should be no penalty. Its not easy to keep the speed exact, unless there's cruise control.

Faster trains = shorter journeys = more (or equal) service with less train sets. 

[LGA Link N Train]

4 hours ago, Jcb said:

It's kind of interesting how everyone settled on CBTC as the answer. Although it absolutely has its merits, are there any examples of it scaling up to a system with as much interlining and possibility of reroute?

 

In the interim, though, the MTA has been given lemons. They aren't making the lemonade that they could be. 

 

3 hours ago, rbrome said:

You're saying that 100-year-old technology is better suited to a very complex system than modern computer technology? That doesn't even begin to make sense. 

The old signal system relies on (mechanical) parts that are inevitably prone to wear and breakdowns, something we've all experienced. CBTC is solid-state, which can be far more reliable (when designed correctly) and can include self-diagnostic features so problems can be identified and fixed much faster. Ideally the MTA would move to 100% CBTC as quickly as possible, and benefit from vastly improved reliability overall. 

I don't think that CBTC is the answer to fixing our subway issues at all. HOWEVER, I do see it as a Crucial component to fixing our subway system. Another component I agree with what @RR503 and others said about operating the current Fixed Block signaling system at Full Potential and whatnot. Without it, our subway system will just get worse. I do think that the could go for something BETTER than CBTC. What is it? I'm not particularly sure myself.

[RR503]

5 hours ago, Lance said:

While there are major operational issues that need to be addressed (timer placement, fumigation, etc.), the problem itself is two-fold. The other half of the problem is the positively ancient signaling system that's in place. While those ideas mentioned above are a good start for fixing the bulk of the issues short-term, as a long-term goal, the signal system has to be replaced regardless. Whether that's through the CBTC system or other conventional signaling depends on who's asked and possible location. On the subject of CBTC itself, perhaps it's an over-reliance on computers to run trains these days, but the fact remains that several major transit agencies worldwide have shifted over to this particular system, which should be a testament to its benefits, despite the costs involved. Either way, we cannot hope to resolve all of the problems plaguing the subway's operation by simply removing the operational hurdles. We have to fix the underlying problem as well.

Age really isn't too correlated with basic function. I don't think I need to remind you that the Moscow Metro achieves throughputs higher than most CBTC systems with fixed blocks. That said, it is incontrovertible that CBTC is more capable than fixed blocks -- you can introduce new braking rates and train lengths with ease -- so yes, it should be installed.

Where I draw issue is with the way it's being approached. I'm honestly apathetic about installation timeline here -- money is cheaper sooner, but disruptions are more manageable over the long term. The problem is that the way the system itself is installed is unnecessarily costly and disruptive, to say nothing of restrictive of future operation. So I question whether or not the cost/benefit analysis works out in installation's favor without some changes. Currently, the structure of involved contracts is usually nonsensical, the work plan really speaking does not exist, and the installation process involves a ground up rebuild of the fixed block system (followed by its almost complete destruction). When untold billions of dollars are on the line, I think the only responsible plan of action is to optimize what you have, optimize what you want, and then analyze. 

[Deucey]

9 hours ago, rbrome said:

You're saying that 100-year-old technology is better suited to a very complex system than modern computer technology? That doesn't even begin to make sense. 

The old signal system relies on (mechanical) parts that are inevitably prone to wear and breakdowns, something we've all experienced. CBTC is solid-state, which can be far more reliable (when designed correctly) and can include self-diagnostic features so problems can be identified and fixed much faster. Ideally the MTA would move to 100% CBTC as quickly as possible, and benefit from vastly improved reliability overall. 

I believe (haven't read beyond your post) that @Lawrence Stmay be concerned with something analogous to the Trolley Problem and self-driving cars when it comes to CBTC. 

Here's an example of what I think he's worried about: 

There's a section of track on the uptown 7th Av line express where if you're in the right part of Canal St station, you can see the track bend as a train rolls over it because the distance between the track ties is longer than normal.

If CBTC says go 50 in that zone while a T/O would go 30 - because the bend is dramatic enough to cause the train to sway more or potentially jump the track, or the track circuitry fails to show it's broken, how do CBTC algorithms account for either of these?

If I'm accurate, that's the human hands aspect he's preferring - experience and sightlines.

(Trolley Problem write-up: https://www.sciencefriday.com/segments/self-driving-cars-are-bringing-the-trolley-problem-into-the-real-world/)

 

[Lawrence St]

30 minutes ago, Deucey said:

I believe (haven't read beyond your post) that @Lawrence Stmay be concerned with something analogous to the Trolley Problem and self-driving cars when it comes to CBTC. 

Here's an example of what I think he's worried about: 

There's a section of track on the uptown 7th Av line express where if you're in the right part of Canal St station, you can see the track bend as a train rolls over it because the distance between the track ties is longer than normal.

If CBTC says go 50 in that zone while a T/O would go 30 - because the bend is dramatic enough to cause the train to sway more or potentially jump the track, or the track circuitry fails to show it's broken, how do CBTC algorithms account for either of these?

If I'm accurate, that's the human hands aspect he's preferring - experience and sightlines.

(Trolley Problem write-up: https://www.sciencefriday.com/segments/self-driving-cars-are-bringing-the-trolley-problem-into-the-real-world/)

 

This is what I mean. Like, if a rail breaks on lets say the  between 1st Avenue and Bedford Avenue, and CBTC can't detect it, it will continue to go at the posted speed and the consequence can be deadly. This is why I prefer motorman. 

[RR503]

In a rare moment of free time over this past weekend, I sat down with NYMTC's hub bound reports and the 1949 and '54 BOT service maps (big thanks to Stephen Bauman for this resource and general help). I wanted to analyze the way peak hour (8-9AM) subway capacity and ridership had changed over the years, to help contextualize all the strum und drang about CBTC, and the perceived lack of capacity in the system. The initial (I'm still very much working on this) results of these analyses are below.

So we all know that rhetoric around capacity is questionable; system operation/service design is more of a constraint than folks appreciate. Just how questionable? Well...

Each point represents a year for which I could find data. The red point was maximum recorded capacity (I'm relatively certain it went even higher in the early 60s, though I couldn't find a source to corroborate), and the dashed line is the number of trains we could run into the core if we ran 30tph on every track (yes, I am aware that that's a reductive assumption). The increases in that last data point in '89 and '17 are 63rd and SAS, respectively. (On a methodological note, I excluded the 3rd Ave. El from these charts to strengthen my case)

That chart alone is an indictment of NYCT's backwards polices. Operational incompetence, circularity in service guidelines, and sheer ignorance have driven a significant loss in peak-hour capacity -- one that has taken place in the face of an overall system track capacity increase. The corridor-by-corridor breakdowns of this loss are below: 

What makes this all the more stinging is the associated change in ridership. It would be one thing if the MTA's operational incompetence had been met with increasing ridership; that would at least provide a modicum of reason for the spate of dwell-associated delays we have seen. But no. In what came as a surprise to me, peak-hour ridership is actually down significantly from the '70s (the earliest time period for which I could find such data). In 1973, peak-hour core bound ridership was 478,110. Today, it's 373,011. That decrease (of about 22%) is in fact so large that on a passengers/train basis, the subway is actually less stressed today than it was back then (an average of 1146 people per train in 1973, versus 1059 today). As folks will correctly point out, pax/train ignores train length and car size, but with 10-car trains now all but universal on the IND/IRT, I'd posit that the people/square foot impact has been equally positive (that analysis is in the works). 

What I believe this speaks to is the obfuscatory nature of the push for CBTC. There is historical precedent for more core-bound throughput and higher fixed-block capacities; there is current precedent for passably competent block signal ops (QB express comes to mind). In the end, CBTC is just a mediator of train spacing, one whose performance is not determined by its technology, but by the variables that determine transit capacity otherwise (acceleration, braking, dwell time, schedule adherence). I do not deny that CBTC is vastly more flexible than fixed-block, but given its cost and the existence of all this unused capacity, do we really believe that it's the wisest use of 40 billion? Can't we just install incrementally, and reinvest in basic maintenance? Please, please share your thoughts. I will be posting more of these analyses as time goes on. 

________

If any of you are interested in the spreadsheets involved here, please PM me -- as with everything else I have/will post here, I'm happy to share. 

Edited November 26, 2018 by RR503

[Wallyhorse]

Actually, that's not as a big as surprise as it looks:

The BIGGEST reason by far for that is the FACT we no longer live in an exclusively 9-5 world any longer.  Many companies today have to stagger their work hours to meet demands, plus in a global economy companies that years ago never had to be open to accommodate Euro/Asian markets for example now do.    What used to be the AM and PM rush hours are now much more spread out, with PM rush to some degree actually running well past 8:00 and even 9:00 PM in some cases whereas it used to be winding down around 6:30.  The traditional rush hours are not quite what they once were with things much more spread out than in years past. 

[RailRunRob]

17 hours ago, RR503 said:

In a rare moment of free time over this past weekend, I sat down with NYMTC's hub bound reports and the 1949 and '54 BOT service maps (big thanks to Stephen Bauman for this resource and general help). I wanted to analyze the way peak hour (8-9AM) subway capacity and ridership had changed over the years, to help contextualize all the strum und drang about CBTC, and the perceived lack of capacity in the system. The initial (I'm still very much working on this) results of these analyses are below.

So we all know that rhetoric around capacity is questionable; system operation/service design is more of a constraint than folks appreciate. Just how questionable? Well...

Each point represents a year for which I could find data. The red point was maximum recorded capacity (I'm relatively certain it went even higher in the early 60s, though I couldn't find a source to corroborate), and the dashed line is the number of trains we could run into the core if we ran 30tph on every track (yes, I am aware that that's a reductive assumption). The increases in that last data point in '89 and '17 are 63rd and SAS, respectively. (On a methodological note, I excluded the 3rd Ave. El from these charts to strengthen my case)

That chart alone is an indictment of NYCT's backwards polices. Operational incompetence, circularity in service guidelines, and sheer ignorance have driven a significant loss in peak-hour capacity -- one that has taken place in the face of an overall system track capacity increase. The corridor-by-corridor breakdowns of this loss are below: 

What makes this all the more stinging is the associated change in ridership. It would be one thing if the MTA's operational incompetence had been met with increasing ridership; that would at least provide a modicum of reason for the spate of dwell-associated delays we have seen. But no. In what came as a surprise to me, peak-hour ridership is actually down significantly from the '70s (the earliest time period for which I could find such data). In 1973, peak-hour core bound ridership was 478,110. Today, it's 373,011. That decrease (of about 22%) is in fact so large that on a passengers/train basis, the subway is actually less stressed today than it was back then (an average of 1146 people per train in 1973, versus 1059 today). As folks will correctly point out, pax/train ignores train length and car size, but with 10-car trains now all but universal on the IND/IRT, I'd posit that the people/square foot impact has been equally positive (that analysis is in the works). 

What I believe this speaks to is the obfuscatory nature of the push for CBTC. There is historical precedent for more core-bound throughput and higher fixed-block capacities; there is current precedent for passably competent block signal ops (QB express comes to mind). In the end, CBTC is just a mediator of train spacing, one whose performance is not determined by its technology, but by the variables that determine transit capacity otherwise (acceleration, braking, dwell time, schedule adherence). I do not deny that CBTC is vastly more flexible than fixed-block, but given its cost and the existence of all this unused capacity, do we really believe that it's the wisest use of 40 billion? Can't we just install incrementally, and reinvest in basic maintenance? Please, please share your thoughts. I will be posting more of these analyses as time goes on. 

________

If any of you are interested in the spreadsheets involved here, please PM me -- as with everything else I have/will post here, I'm happy to share. 

Man somebody's been working love it!!  We should try to get these data points into some type of simulation.

[N6 Limited]

As we can see, the subway has had more throughput in the past, since they severely slowed down trains and have faulty timers everywhere, it's limiting throughput. Many passengers just LOATH the slow movement of the trains, it's irritating.  If we're going to be cruising at 10-20mph , might as well be in a FHV above ground where you can look out the window.

CBTC is an excuse to build the foundation of OPTO or driverless operation.

[Around the Horn]

I would love to see a comparison between this data and a similar look in throughput throughout the years in cities like London, which have already taken the CBTC leap (if the data is available to make such a comparison)

In any event, going from 494 TPH in the core in 1954 to only 363 TPH in 2017 (a decrease of 131 [!!!] ) is not good...

[RR503]

46 minutes ago, Around the Horn said:

I would love to see a comparison between this data and a similar look in throughput throughout the years in cities like London, which have already taken the CBTC leap (if the data is available to make such a comparison)

 In any event, going from 494 TPH in the core in 1954 to only 363 TPH in 2017 (a decrease of 131 [!!!] ) is not good...

I would too; certainly an interesting phase 2 for this project. 

My general thesis, though, is that last bit. We've got to forget about how other systems may or may not squeeze out an extra 3 or 4 tph w/ competent CBTC ops. Their histories (really, lack of '80s financial crisis/mismanagement) will put their baseline in a different place. I think we've got to step back from all the excitement about an extra 2tph on QB express, or an extra 1 on the Lex, and see that we've somehow ended up 237 tph below the international baseline (30tph/track). Sure, certain corridors/areas are more stressed than others, but that reality in and of itself is flexible; people gravitate towards frequent trains, which, given our system's use of loading guidelines, means that crowding and frequency 'collude' to make the former worse. (This will be my next analysis, btw). 

Edited November 27, 2018 by RR503

[bobtehpanda]

Just to clarify; is this scheduled or real service?

It's worth noting that 1954, IIRC, is before the completion of Chrystie St (1968), the introduction of 75 ft cars with less door area, and the lengthening of platforms to ten cars long across the system. The disadvantage of longer trains is that they require longer blocks and take longer to clear interlockings, and less doors would increase dwells, but I don't know how much of a real effect that would have on max TPH.

[RR503]

57 minutes ago, bobtehpanda said:

Just to clarify; is this scheduled or real service?

Ah! Totally neglected to talk about this — thanks. The 1949 and ‘54 data points are both scheduled service. NYMTC doesn’t say explicitly, but the extreme year-to-year variation and slightly-below-GTFSness their data displays suggests it’s real service. For the 1949 and ‘54 data points, though, it’s a relatively fair assumption that scheduled = real. If you look at page 35 of the 1949 report I linked, you’ll see that the IRT had an OTP of 87%, and the BMT/IND of >99% for that year; I’d imagine >95% of trains were running. 

1 hour ago, bobtehpanda said:

It's worth noting that 1954, IIRC, is before the completion of Chrystie St (1968), the introduction of 75 ft cars with less door area, and the lengthening of platforms to ten cars long across the system. The disadvantage of longer trains is that they require longer blocks and take longer to clear interlockings, and less doors would increase dwells, but I don't know how much of a real effect that would have on max TPH.

Longer trains really only come into play on BMT Broadway; you’ll notice that the ‘54 map depicts 10 car compatibility across the IRT as complete. I can’t find good, hard data for Bway after that ‘54 map (the only other available point is a Chrystie-related service change poster, which IINM predates platform lengthening completion on the corridor). IRT and IND precedent suggest that longer trains can coexist with higher frequencies (look at that 34tph on CPW express in 1949), but given that basic block lengths may not have been changed along Broadway, there may have been some penalty. 

75’ cars really only cause dwell increases in high crowding situations. That certainly doesn’t help on corridors like QB, but given the overall decline in peak ridership, I’d wonder if the doors/core bound peak rider ratio would be all that far off... Certainly an issue, though — though not one expletive of the 131tph drop, and 257tph deficiency...

[bobtehpanda]

4 minutes ago, RR503 said:

Longer trains really only come into play on BMT Broadway; you’ll notice that the ‘54 map depicts 10 car compatibility across the IRT as complete. I can’t find good, hard data for Bway after that ‘54 map (the only other available point is a Chrystie-related service change poster, which IINM predates platform lengthening completion on the corridor). IRT and IND precedent suggest that longer trains can coexist with higher frequencies (look at that 34tph on CPW express in 1949), but given that basic block lengths may not have been changed along Broadway, there may have been some penalty. 

This old NYT article suggests that lengthening was ongoing in 1964, at least along 7th Avenue.

I only bring in Chrystie St because prior to that, the three separate systems don't have any crazy service patterns going on. Post Chrystie St complexity shoots through the roof.

[RR503]

15 minutes ago, bobtehpanda said:

I only bring in Chrystie St because prior to that, the three separate systems don't have any crazy service patterns going on. Post Chrystie St complexity shoots through the roof.

While that’s certainly true, they dealt with that quite well. Whitehall somehow managed to turn 15tph, Dekalb processed 80tph with full interlining (and, for all we know, could have done more; they artificially lowered frequencies on Bway Exp to 20tph to push folks towards 6th post-Chrystie), we had 60tph/direction through 59... What was lost in the years since then was the ability to manage complexity. Unless it affects a reduction in absolute capacity, interlining isn’t a *terrible* thing — it just needs competent operators. 

[Jsunflyguy]

Some things to keep in mind, in 1947 the 3rd Ave El still existed and would run about 60 trains per hour across the river from the Bronx, another thing that has to be normalized for is train lengths. Putting a 600ft train through an interlocking takes 27 seconds, whereas a BMT 6 car train takes 16 seconds and an 8 car train takes 22 seconds. So there is a time penalty as train lengths increase. Also those trains clear their blocks faster and can be turned in station faster since there's less walking. What would be interesting is passenger capacity per hour.

[RR503]

15 minutes ago, Jsunflyguy said:

Some things to keep in mind, in 1947 the 3rd Ave El still existed and would run about 60 trains per hour across the river from the Bronx, another thing that has to be normalized for is train lengths. Putting a 600ft train through an interlocking takes 27 seconds, whereas a BMT 6 car train takes 16 seconds and an 8 car train takes 22 seconds. So there is a time penalty as train lengths increase. Also those trains clear their blocks faster and can be turned in station faster since there's less walking. What would be interesting is passenger capacity per hour.

I excluded 3rd Ave El from my calcs for precisely this reason; wanted to analyze what we once did w/ the infrastructure that exists today. 

In '49 and '54, most of the IND was running 8- or 10- car trains, and most of the BMT 8. QB express, in fact, has 11 car trains in that '54 map. On the IRT, expresses all have 10 car trains, but the IRT locals not so much -- 7th seems to still be running 5 car trains (though the map indicates that the signal system is capable of handling 30 10 car trains/hour), and Lex averages out at around 8 cars.  

Insofar as terminal ops, train length only matters if you're entering and leaving with the same crew. Needless to say, that isn't a best practice. Most systems either have crews waiting at the departing end of the terminal and/or double end with the departing crew when entering relay. 

Passenger capacity in the peak hour over time is forthcoming. I can tell you, though, that in 1954 we ran 4221 cars into the core. Today, it's 3,278 -- a 22% decrease. 

[Deucey]

4 hours ago, RR503 said:

I excluded 3rd Ave El from my calcs for precisely this reason; wanted to analyze what we once did w/ the infrastructure that exists today. 

In '49 and '54, most of the IND was running 8- or 10- car trains, and most of the BMT 8. QB express, in fact, has 11 car trains in that '54 map. On the IRT, expresses all have 10 car trains, but the IRT locals not so much -- 7th seems to still be running 5 car trains (though the map indicates that the signal system is capable of handling 30 10 car trains/hour), and Lex averages out at around 8 cars.  

Insofar as terminal ops, train length only matters if you're entering and leaving with the same crew. Needless to say, that isn't a best practice. Most systems either have crews waiting at the departing end of the terminal and/or double end with the departing crew when entering relay. 

Passenger capacity in the peak hour over time is forthcoming. I can tell you, though, that in 1954 we ran 4221 cars into the core. Today, it's 3,278 -- a 22% decrease. 

Just wondering, for the trains ending in loops then (today's ), do you have to factor in crew changes in or after the loop (if they did those then) or rest breaks (if the crew downtown went back uptown in the same train)?